[openstack-dev] [neutron][nova] Config drive claims ipv6_dhcp, neutron api says slaac

[Clark Boylan]

Hello,

The infra team ran into glean not being able to correctly configure host
interfaces on boot. The trigger for this appears to be this change to
nova which enabled ipv6 in metadata/config drive [0]. I don't think
there is anything wrong with this but it exposed another interesting
behavior.

The config drive network_data.json is:
{
"links": [
{
"ethernet_mac_address": "fa:16:3e:9e:84:5c",
"id": "tap14b906ba-8c",
"mtu": 1450,
"type": "ovs",
"vif_id": "14b906ba-8c2c-4829-852e-2987d25ceabc"
}
],
"networks": [
{
"id": "network0",
"link": "tap14b906ba-8c",
"network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
"type": "ipv4_dhcp"
},
{
"id": "network1",
"link": "tap14b906ba-8c",
"network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
"type": "ipv6_dhcp"
}
],
"services": []
}

You'll notice that the network1 entry has a type of ipv6_dhcp; however,
if you ask the neutron api it tells slaac is the ipv6_address_mode and
ipv6_ra_mode. But enable_dhcp is also set to True. So which is it? Is
there a bug here or am I missing something obvious? At the very least it
appears that the config drive info is incomplete and does not include
the slaac info.

clarkb@ubuntu-xenial-internap-mtl01-8040461:~$ openstack --os-cloud
devstack network show 7ee08c00-7323-4f18-94bb-67e081520e70
+---++
| Field | Value 
|
+---++
| admin_state_up| UP
|
| availability_zone_hints   |   
|
| availability_zones| nova  
|
| created_at| 2017-03-23T14:35:33Z  
|
| description   |   
|
| dns_domain| None  
|
| id| 7ee08c00-7323-4f18-94bb-67e081520e70  
|
| ipv4_address_scope| None  
|
| ipv6_address_scope| None  
|
| is_default| None  
|
| mtu   | 1450  
|
| name  | private   
|
| port_security_enabled | True  
|
| project_id| 46dd6a74cf244079a4f97ba1fc493793  
|
| provider:network_type | None  
|
| provider:physical_network | None  
|
| provider:segmentation_id  | None  
|
| qos_policy_id | None  
|
| revision_number   | 7 
|
| router:external   | Internal  
|
| segments  | None  
|
| shared| False 
|
| status| ACTIVE
|
| subnets   | 2cbae31d-27be-42aa-b543-b2baa5e52130,
92664772-b719-4b2d-9d47-e657be990c0b |
| updated_at| 2017-03-23T14:35:40Z  
|
+---++
clarkb@ubuntu-xenial-internap-mtl01-8040461:~$ openstack --os-cloud
devstack subnet show 2cbae31d-27be-42aa-b543-b2baa5e52130
+---++
| Field | Value 
|
+---++
| allocation_pools  |

Re: [openstack-dev] [tripleo] patch abandoment policy

[Jason E. Rist]

On 03/23/2017 04:20 PM, Alex Schultz wrote:
> Hey folks,
>
> So after looking at the backlog of patches to review across all of the
> tripleo projects, I noticed we have a bunch of really old stale
> patches. I think it's time we address when we can abandon these stale
> patches.
>
> Please comment on the proposed policy[0].  I know this has previously
> been brought up [1] but I would like to formalize the policy so we can
> reduce the backlog of stale patches.  If you're wondering what would
> be abandoned by this policy as it currently sits, I have a gerrit
> dashboard for you[2] (it excludes diskimage-builder) .
>
> Thanks,
> -Alex
>
> [0] https://review.openstack.org/#/c/449332/
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/07.html
> [2] https://goo.gl/XC9Hy7
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I have no comments. It looks good from the TripleO-UI perspective.

__
OpenStack Development Mailing 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] patch abandoment policy

[Alex Schultz]

Hey folks,

So after looking at the backlog of patches to review across all of the
tripleo projects, I noticed we have a bunch of really old stale
patches. I think it's time we address when we can abandon these stale
patches.

Please comment on the proposed policy[0].  I know this has previously
been brought up [1] but I would like to formalize the policy so we can
reduce the backlog of stale patches.  If you're wondering what would
be abandoned by this policy as it currently sits, I have a gerrit
dashboard for you[2] (it excludes diskimage-builder) .

Thanks,
-Alex

[0] https://review.openstack.org/#/c/449332/
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-October/07.html
[2] https://goo.gl/XC9Hy7

__
OpenStack Development Mailing 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][ui] [heat] i18n proposal for heat templates 'description' help strings

[Zane Bitter]

On 23/03/17 04:39, Peng Wu wrote:

Hi,

  For TripleO UI project, some users requested to translate the web UI.
But some web UI string are from heat template files in tripleo-heat-
templates project.

  In order to get translated templates displayed in tripleo-ui, we
propose a blueprint as follows, which needs to change code in heat,
tripleo-heat-tempates and tripleo-ui projects.

  I18n proposal for heat templates 'description' help strings

  1. Update heat project to accept "translation-domain" header in
RESTful request, like "translation-domain: tripleo-heat-templates"

 a. With "translation-domain" header, heat will try to translate
"title" and "description" field using "tripleo-heat-templates.po"

 b. Without "translation-domain" header, heat will return the
fields like before

 c. Add some field in config file for security to have a list of
allowed "translation-domain",
like "allowed-translation-domains: ['tripleo-heat-templates',
...]"


I agree with Thomas, Heat is the _last_ place you should be looking to 
do the translation. Personally, I think this is yet another entry in a 
long list of "why TripleO should generate its Heat templates". (Some of 
the templates are actually preprocessed with Jinja2 now, so it may be 
possible to work translation in there.) A poor substitute for that might 
be to translate stuff in the TripleO UI itself. What will never ever 
make sense is for Heat to include a list of strings that might possibly 
have occurred in application templates at some point in the past and 
their translations.



  2. Update tripleo-heat-templates to generate the translation files,
 like "tripleo-heat-templates.pot"

 a. May need to write python script to extract "title" and
"description" field from yaml files

 b. May need to integrate into python babel config or use separate
po files


  3. Update tripleo-ui to use locale API with "translation-domain"
header to ask the RESTful response with translated "title" and
"description" fields from heat services

 a. tripleo-ui will send request with two additional headers:
"Accept-Language" and "translation-domain: tripleo-heat-
templates"

  Please evaluate it, thanks!

Regards,
  Peng

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




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

[openstack-dev] [all][api] POST /api-wg/news

[Chris Dent]

Greetings OpenStack community,

An after an initially slow start, today's meeting turned into a rollicking good 
time. Probably because we talked about microversions.

First we discussed the need to clarify that the API-WG is governed by TC 
(Technical Committee) not the UC (User Committee). The rule of thumb for 
working groups is: did you go to the PTG or the Ops Meetup. We went to the PTG 
and had two very productive days. Over the next few days we'll find the bits of 
documentation that need to be cleared up and make sure pointers point the right 
places.

We then discussed whether the point of the API-WG is the guidelines it creates 
or the discussions that lead to the creation of those guidelines and the 
overall better understanding of how to achieve consistency and correctness in 
OpenStack APIs. What was first thought of as a fairly simple question turned 
into a spirited debate spiralling out to a plan to audit the API-WG's mission 
statement [2] for its own consistency and correctness. elmiko has the ball for 
that, but since he'll be away next week we won't pick it up until the week 
following.

We moved on from there to talk about the stability guidelines (linked in under 
review below). We're getting very close, but are stuck on whether it is 
worthwhile including some information about alternatives (either expressing 
them as true alternatives, or explaining why they won't work). edleafe and 
mugsie are going to work to bring this to a close next week. If you are 
interested in this topic the logs at 
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-03-23-16.00.log.html#l-116
 may be worth a look.

This summary does not do justice to the level of investment and interest that 
was present in today's meeting. Thanks to everyone who showed up.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community. Nothing at 
the moment, but feel free to get in early on the reviews below.

# Guidelines Currently Under Review [3]

* Define pagination guidelines (recently rebooted)
  https://review.openstack.org/#/c/446716/

* Create a new set of api stability guidelines
  https://review.openstack.org/#/c/421846/

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
  https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [craton] Nomination of Thomas Maddox as Craton core

[Jim Baker]

We can now call this vote: 4 out of 4 of the active cores, all +1. Welcome
to the team, Thomas!

On Thu, Mar 23, 2017 at 11:28 AM, git harry  wrote:

> +1
>
> --
> *From:* Jim Baker 
> *Sent:* 21 March 2017 20:41
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [craton] Nomination of Thomas Maddox as Craton
> core
>
> *I nominate Thomas Maddox as a core reviewer for the Craton project.*
>
> Thomas has shown extensive knowledge of Craton, working across a range of
> issues in the core service, including down to the database modeling; the
> client; and corresponding bugs, blueprints, and specs. Perhaps most notably
> he has contributed a number of end-to-end patches, such as his work with
> project support.
> https://review.openstack.org/#/q/owner:thomas.maddox
>
> He has also expertly helped across a range of reviews, while always being
> amazingly positive with other team members and potential contributors:
> https://review.openstack.org/#/q/reviewer:thomas.maddox
>
> Other details can be found here on his contributions:
> http://stackalytics.com/report/users/thomas-maddox
>
> In my opinion, Thomas has proven that he will make a fantastic addition to
> the core review team. In particular, I'm confident Thomas will help further
> improve the velocity for our project as a whole as a core reviewer. I hope
> others concur with me in this assessment!
>
> - 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] [craton] Nomination of Thomas Maddox as Craton core

[git harry]

+1


From: Jim Baker 
Sent: 21 March 2017 20:41
To: OpenStack Development Mailing List
Subject: [openstack-dev] [craton] Nomination of Thomas Maddox as Craton core

I nominate Thomas Maddox as a core reviewer for the Craton project.

Thomas has shown extensive knowledge of Craton, working across a range of 
issues in the core service, including down to the database modeling; the 
client; and corresponding bugs, blueprints, and specs. Perhaps most notably he 
has contributed a number of end-to-end patches, such as his work with project 
support.
https://review.openstack.org/#/q/owner:thomas.maddox

He has also expertly helped across a range of reviews, while always being 
amazingly positive with other team members and potential contributors:
https://review.openstack.org/#/q/reviewer:thomas.maddox

Other details can be found here on his contributions:
http://stackalytics.com/report/users/thomas-maddox

In my opinion, Thomas has proven that he will make a fantastic addition to the 
core review team. In particular, I'm confident Thomas will help further improve 
the velocity for our project as a whole as a core reviewer. I hope others 
concur with me in this assessment!

- 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] [neutron][networking-l2gw] Unable to create release tag

[Yolanda Robla Mota]

Hi, seems the ACL is not correctly applied. infra-root as looking at it

Best
Yolanda

On Thu, Mar 23, 2017 at 5:18 PM, Gary Kotton  wrote:

> Hi,
> I have tried updating my gpg key and still nothing works:
>
> gkotton@ubuntu:~/networking-l2gw$ git push gerrit tag 10.0.0
> Enter passphrase for key '/home/gkotton/.ssh/id_rsa':
> Counting objects: 1, done.
> Writing objects: 100% (1/1), 531 bytes | 0 bytes/s, done.
> Total 1 (delta 0), reused 0 (delta 0)
> remote: Processing changes: refs: 1, done
> To ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git
>  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
> error: failed to push some refs to 'ssh://garyk@review.openstack.
> org:29418/openstack/networking-l2gw.git'
>
> Any idea here?
> This is blocking people who want to package…
> Thanks
> Gary
>
> On 3/21/17, 7:18 PM, "Gary Kotton"  wrote:
>
> Hi,
> I am still unable to do this – this is after
> https://review.openstack.org/#/c/447279/ landed.
> Any ideas?
> Thanks
> Gary
>
> On 3/14/17, 3:04 PM, "Jeremy Stanley"  wrote:
>
> On 2017-03-14 05:39:35 + (+), Gary Kotton wrote:
> > I was asked to create a release tag for stable/ocata. This fails
> with:
> [...]
> >  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
> [...]
>
> The ACL for that repo doesn't seem to be configured to allow it
> (yet):
>
> http://git.openstack.org/cgit/openstack-infra/project-
> config/tree/gerrit/acls/openstack/networking-l2gw.config
>
> The Infra Manual section documenting that permission is:
>
> https://docs.openstack.org/infra/manual/creators.html#
> creation-of-tags
>
> It also may be helpful to review the section on manually tagging
> releases:
>
> https://docs.openstack.org/infra/manual/drivers.html#
> tagging-a-release
>
> Hope that helps!
> --
> Jeremy Stanley
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCSA

Red Hat



C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639


__
OpenStack Development Mailing 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][networking-l2gw] Unable to create release tag

[Gary Kotton]

Hi,
I have tried updating my gpg key and still nothing works:

gkotton@ubuntu:~/networking-l2gw$ git push gerrit tag 10.0.0
Enter passphrase for key '/home/gkotton/.ssh/id_rsa': 
Counting objects: 1, done.
Writing objects: 100% (1/1), 531 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done
To ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git
 ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
error: failed to push some refs to 
'ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git'

Any idea here?
This is blocking people who want to package…
Thanks
Gary

On 3/21/17, 7:18 PM, "Gary Kotton"  wrote:

Hi,
I am still unable to do this – this is after 
https://review.openstack.org/#/c/447279/ landed.
Any ideas?
Thanks
Gary

On 3/14/17, 3:04 PM, "Jeremy Stanley"  wrote:

On 2017-03-14 05:39:35 + (+), Gary Kotton wrote:
> I was asked to create a release tag for stable/ocata. This fails with:
[...]
>  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
[...]

The ACL for that repo doesn't seem to be configured to allow it
(yet):


http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/networking-l2gw.config

The Infra Manual section documenting that permission is:

https://docs.openstack.org/infra/manual/creators.html#creation-of-tags

It also may be helpful to review the section on manually tagging
releases:

https://docs.openstack.org/infra/manual/drivers.html#tagging-a-release

Hope that helps!
-- 
Jeremy Stanley


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


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


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

[openstack-dev] [nova] Spec review sprint on Tuesday April 4th

[Matt Riedemann]

As discussed in the nova meeting today [1] we will be having a spec 
review sprint on Tuesday April 4th. We have ~111 open specs for review 
and the spec freeze is on April 13th [2] so this will give us a push for 
reviews before the deadline.


We'll be discussing specs in the #openstack-nova IRC channel on that day 
so if you have a spec proposed, please try to be around in the channel 
to answer any questions or quickly address any issues that come up if 
we're looking at your spec.


[1] 
http://eavesdrop.openstack.org/meetings/nova/2017/nova.2017-03-23-14.00.html

[2] https://wiki.openstack.org/wiki/Nova/Pike_Release_Schedule

--

Thanks,

Matt

__
OpenStack Development Mailing 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] [fuel] Weekly meeting March 23th is cancelled

[Vladimir Kuklin]

Agenda is empty for today, so I am calling the meeting as cancelled.

-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Translations removal

[Jim Rollenhagen]

On Wed, Mar 22, 2017 at 11:44 AM, Sean McGinnis 
wrote:

> On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > However, pep8 does not accept passing variable to translation
> > > functions,  so this results in ‘H701 Empty localization string’ error.
> > >
> > > Possible options to handle that:
> > >
> > > 1)  Duplicate messages:
> > >
> > > LOG.error(“”, {: })
> > >
> > > raise Exception(_(“”) % {: })
> > >
> > > 2)  Ignore this error
> > >
> > > 3)  Talk to hacking people about possible upgrade of this check
> > >
> > > 4)  Pass translated text to LOG in such cases
> > >
> > >
> > >
> > > I’d personally vote for 2. What are your thoughts?
> >
> > When the translators go to translate, they generally only get to see
> > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > no-go.
> > --
>
> I think the appropriate thing here is to do something like:
>
> msg = _('') % {: }
> LOG.error(msg)
> raise Exception(msg)
>
> This results in a translated string going to the log, but I think that's
> OK.
>

+1, let's not overcomplicate this. If folks report it as a problem, we
can always go back to option 1 later.

// 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] [tripleo] container jobs are unstable

[Martin André]

On Wed, Mar 22, 2017 at 2:20 PM, Dan Prince  wrote:
> On Wed, 2017-03-22 at 13:35 +0100, Flavio Percoco wrote:
>> On 22/03/17 13:32 +0100, Flavio Percoco wrote:
>> > On 21/03/17 23:15 -0400, Emilien Macchi wrote:
>> > > Hey,
>> > >
>> > > I've noticed that container jobs look pretty unstable lately; to
>> > > me,
>> > > it sounds like a timeout:
>> > > http://logs.openstack.org/19/447319/2/check-tripleo/gate-tripleo-
>> > > ci-centos-7-ovb-containers-oooq-nv/bca496a/console.html#_2017-03-
>> > > 22_00_08_55_358973
>> >
>> > There are different hypothesis on what is going on here. Some
>> > patches have
>> > landed to improve the write performance on containers by using
>> > hostpath mounts
>> > but we think the real slowness is coming from the images download.
>> >
>> > This said, this is still under investigation and the containers
>> > squad will
>> > report back as soon as there are new findings.
>>
>> Also, to be more precise, Martin André is looking into this. He also
>> fixed the
>> gate in the last 2 weeks.
>
> I spoke w/ Martin on IRC. He seems to think this is the cause of some
> of the failures:
>
> http://logs.openstack.org/32/446432/1/check-tripleo/gate-tripleo-ci-cen
> tos-7-ovb-containers-oooq-nv/543bc80/logs/oooq/overcloud-controller-
> 0/var/log/extra/docker/containers/heat_engine/log/heat/heat-
> engine.log.txt.gz#_2017-03-21_20_26_29_697
>
>
> Looks like Heat isn't able to create Nova instances in the overcloud
> due to "Host 'overcloud-novacompute-0' is not mapped to any cell'. This
> means our cells initialization code for containers may not be quite
> right... or there is a race somewhere.

Here are some findings. I've looked at time measures from CI for
https://review.openstack.org/#/c/448533/ which provided the most
recent results:

* gate-tripleo-ci-centos-7-ovb-ha [1]
undercloud install: 23
overcloud deploy: 72
total time: 125
* gate-tripleo-ci-centos-7-ovb-nonha [2]
undercloud install: 25
overcloud deploy: 48
total time: 122
* gate-tripleo-ci-centos-7-ovb-updates [3]
undercloud install: 24
overcloud deploy: 57
total time: 152
* gate-tripleo-ci-centos-7-ovb-containers-oooq-nv [4]
undercloud install: 28
overcloud deploy: 48
total time: 165 (timeout)

Looking at the undercloud & overcloud install times, the most task
consuming tasks, the containers job isn't doing that bad compared to
other OVB jobs. But looking closer I could see that:
- the containers job pulls docker images from dockerhub, this process
takes roughly 18 min.
- the overcloud validate task takes 10 min more than it should because
of the bug Dan mentioned (a fix is in the queue at
https://review.openstack.org/#/c/448575/)
- the postci takes a long time with quickstart, 13 min (4 min alone
spent on docker log collection) whereas it takes only 3 min when using
tripleo.sh

Adding all these numbers, we're at about 40 min of additional time for
oooq containers job which is enough to cross the CI job limit.

There is certainly a lot of room for optimization here and there and
I'll explore how we can speed up the containers CI job over the next
weeks.

Martin

[1] 
http://logs.openstack.org/33/448533/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-ha/d2c1b16/
[2] 
http://logs.openstack.org/33/448533/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-nonha/d6df760/
[3] 
http://logs.openstack.org/33/448533/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-updates/3b1f795/
[4] 
http://logs.openstack.org/33/448533/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq-nv/b816f20/

> Dan
>
>>
>> Flavio
>>
>>
>>
>> _
>> _
>> 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
>
> __
> OpenStack Development Mailing 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] [ptls] Project On-Boarding Rooms

[Flavio Percoco]

On 22/03/17 10:47 +1300, Fei Long Wang wrote:

As far as I know, most of Zaqar team members won't be in Boston. But I
will be there, so pls help put Zaqar on the list if there is one
available. Thanks.


I will be there and I'll try to help, time permitting.

Flavio


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

Re: [openstack-dev] [deployment][tripleo] Next steps for configuration management in TripleO (and other tools?)

[Flavio Percoco]

On 17/03/17 10:09 -0400, Emilien Macchi wrote:

[adding deployment tag because it might be interesting for other tools
since it would engage cross-project work]
If you're not working on TripleO, feel free to comment on how your
team plans to solve the problem (or don't), so we can maybe discuss
and work together.

Hey,

Things are moving in OpenStack deployment tools and we're working on
solving common challenges in a consistent way. We had different topics
and threads about key/value store for configuration management, and
I've been thinking how it could fit with TripleO roadmap:
https://etherpad.openstack.org/p/tripleo-etcd-transition

Feel free to bring any feedback in this thread or even better in the etherpad.


Hey,

Sorry for the delay but: PTO + PTO-backlog!

I actually like the proposal as I also mentioned in the more general thread.
Before we do anything on the tripleo side, I think we should work with the rest
of the openstack community on the common solution, which seems to be leading to
etcd.

As far as the containers effort goes, this move (assuming etcd is the chosen
technology) would work just fine. I don't think this would be useful or even
consumed during the first phase of the containerized overcloud, which uses
docker daemon.

Flavio

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

Re: [openstack-dev] ARA - Ansible Run Analysis: Would you like to help ?

[David Moreau Simard]

On Thu, Mar 23, 2017 at 7:49 AM, Paul Belanger  wrote:
> Yes?

Yay \o/

>
> We are in the process of shutting down puppetboard.o.o for openstack-infra. 
> I'd
> like to get an infra-spec in place to potentially use ARA for our ansible 
> runs.
> So it is possible you'll get some patches your way.

Let me know if you need help getting that going !

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

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

Re: [openstack-dev] [TripleO]:triple-o undercloud installation error on CentOS7.3

[Alex Schultz]

On Thu, Mar 23, 2017 at 7:43 AM, pranab boruah
 wrote:
> Hi, I am trying to install triple-o undercloud on a physical machine.
> The installation fails every time. I have reinstalled the OS and tried
> starting from scratch but got the same error.
>
> System Details :
>
> DELL t620 with IPMI support.
> Different network for Internet Connectivity and PXE respectively.
> OS version : CentOS 7.3.1611, kernel : 3.10.0-514.10.2.el7.x86_64
> 192.168.10.0/24 is for PXE boot network
>
> My undercloud.conf looks like this:
>
> http://paste.openstack.org/show/603918/
>
> Error details:
>
> dib-run-parts Thu Mar 23 18:35:53 IST 2017 Running
> /usr/libexec/os-refresh-config/configure.d/50-puppet-stack-config
> + set -o pipefail
> + puppet_apply puppet apply --detailed-exitcodes
> /etc/puppet/manifests/puppet-stack-config.pp
> + set +e
> + puppet apply --detailed-exitcodes
> /etc/puppet/manifests/puppet-stack-config.pp
> + awk '{print strftime("%Y-%m-%d %H:%M:%S") " - "$0; fflush()}'
> 2017-03-23 18:35:57 - Error: Syntax error at 'Boolean'; expected
> ')' at /etc/puppet/modules/rabbitmq/manifests/init.pp:3
> on node undercloud.in.caveonetworks.com
> 2017-03-23 18:35:57 - Error: Syntax error at 'Boolean'; expected
> ')' at /etc/puppet/modules/rabbitmq/manifests/init.pp:3 on node
> undercloud.in.caveonetworks.com
> + rc=1
> + set -e
> + echo 'puppet apply exited with exit code 1'
> puppet apply exited with exit code 1
> + '[' 1 '!=' 2 -a 1 '!=' 0 ']'
> + exit 1
> [2017-03-23 18:35:57,659] (os-refresh-config) [ERROR] during
> configure phase. [Command '['dib-run-parts',
> '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit
> status 1]
>

What version of puppet do you have installed? I believe you have
version 3 and you need 4.

Thanks,
-Alex

> [2017-03-23 18:35:57,660] (os-refresh-config) [ERROR] Aborting...
>
> Desperately need some help. Please let me know if you  need any other details.
>
> -pjb
>
> __
> OpenStack Development Mailing 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]:triple-o undercloud installation error on CentOS7.3

[pranab boruah]

Hi, I am trying to install triple-o undercloud on a physical machine.
The installation fails every time. I have reinstalled the OS and tried
starting from scratch but got the same error.

System Details :

DELL t620 with IPMI support.
Different network for Internet Connectivity and PXE respectively.
OS version : CentOS 7.3.1611, kernel : 3.10.0-514.10.2.el7.x86_64
192.168.10.0/24 is for PXE boot network

My undercloud.conf looks like this:

http://paste.openstack.org/show/603918/

Error details:

dib-run-parts Thu Mar 23 18:35:53 IST 2017 Running
/usr/libexec/os-refresh-config/configure.d/50-puppet-stack-config
+ set -o pipefail
+ puppet_apply puppet apply --detailed-exitcodes
/etc/puppet/manifests/puppet-stack-config.pp
+ set +e
+ puppet apply --detailed-exitcodes
/etc/puppet/manifests/puppet-stack-config.pp
+ awk '{print strftime("%Y-%m-%d %H:%M:%S") " - "$0; fflush()}'
2017-03-23 18:35:57 - Error: Syntax error at 'Boolean'; expected
')' at /etc/puppet/modules/rabbitmq/manifests/init.pp:3
on node undercloud.in.caveonetworks.com
2017-03-23 18:35:57 - Error: Syntax error at 'Boolean'; expected
')' at /etc/puppet/modules/rabbitmq/manifests/init.pp:3 on node
undercloud.in.caveonetworks.com
+ rc=1
+ set -e
+ echo 'puppet apply exited with exit code 1'
puppet apply exited with exit code 1
+ '[' 1 '!=' 2 -a 1 '!=' 0 ']'
+ exit 1
[2017-03-23 18:35:57,659] (os-refresh-config) [ERROR] during
configure phase. [Command '['dib-run-parts',
'/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit
status 1]

[2017-03-23 18:35:57,660] (os-refresh-config) [ERROR] Aborting...

Desperately need some help. Please let me know if you  need any other details.

-pjb

__
OpenStack Development Mailing 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] - no drivers meeting today

[Kevin Benton]

Hi,

Due to time conflicts with the new drivers meeting time, let's not meet
this week while we try to find a time that works for everyone.

Please take the same block of time to review the RFE's in the triaged state:

bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged=rfe
__
OpenStack Development Mailing 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] ARA - Ansible Run Analysis: Would you like to help ?

[Paul Belanger]

On Wed, Mar 22, 2017 at 04:42:34PM -0400, David Moreau Simard wrote:
> Hi openstack-dev,
> 
> There's this project I'm passionate that I want to tell you about: ARA [1].
> So, what's ARA ?
> 
> ARA is an Ansible callback plugin that you can set up anywhere you run
> Ansible today.
> The next time you run an ansible-playbook command, it'll automatically
> record and organize all the data and provide an intuitive interface
> for you to browse the playbook results.
> 
> In practice, you can find a video demonstration of what the user
> interface looks like here [2].
> 
> ARA doesn't require you to change your existing workflows, it doesn't
> require you to re-write your playbooks.
> It's offline, self-contained, standalone and decentralized by default.
> You can run it on your laptop for a single playbook or run it across
> thousands of runs, recording millions of tasks in a centralized
> database.
> You can read more about the project's core values and philosophies in
> the documented manifesto [3].
> 
> ARA is already used by many different projects that leverage Ansible
> to fulfill their needs, for example:
> - OpenShift-Ansible
> - OpenStack-Ansible
> - Kolla-Ansible
> - TripleO-Quickstart
> - Browbeat
> - devstack-gate
> 
> ARA's also garnered quite a bit of interest outside the OpenStack
> community and there is already a healthy amount of users hanging out
> in IRC on #ara.
> 
> So, it looks like the project is going well. Why am I asking for help ?
> 
> ARA has been growing in popularity, that's definitely something I am
> very happy about.
> However, this also means that there are more users, more feedback,
> more questions, more bugs, more feature requests, more use cases and
> unfortunately, ARA doesn't happen to be my full time job.
> ARA is a tool that I created to make my job easier !
> 
> Also, as much as I hate to admit it, I am by no means a professional
> python developer -- even less so in frontend (html/css/js).
> Being honest, there are things that we should be doing in the project
> that I don't have the time or the skills to accomplish.
> 
> Examples of what I would need help with, aside from what's formally on
> StoryBoard [4]:
> - Help the community (answer questions, triage bugs, etc)
> - Flask experts (ARA is ultimately a flask application)
> - Better separation of components (decouple things properly into a
> server/client/api interface)
> - Full python3 compatibility, test coverage and gating
> - Improve/optimize SQL models/performance
> 
> Contributing to ARA in terms of code is no different than any other
> OpenStack project but I've documented the process if you are not
> familiar with it [5].
> ARA has good unit and integration test coverage and I love to think
> it's not a project that is hard to develop for.
> 
> If you feel the project is interesting and would like to get involved,
> I'd love to welcome you on board.
> 
> Let's chat.
> 
Yes?

We are in the process of shutting down puppetboard.o.o for openstack-infra. I'd
like to get an infra-spec in place to potentially use ARA for our ansible runs.
So it is possible you'll get some patches your way.

-PB

__
OpenStack Development Mailing 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] [networking-sfc]PPG reuse restriction

[Vikash Kumar]

Hi Team,

  I inserted a single arm SF. Created a port-pair with ingress-port and
egress-port as same. Created rest of the resource and it traffic was as
expected through SF in one direction. After, that I tried to create reverse
flow and it failed due to:

   a. reverse port-chain create failed as ppg in use.
   b. port-pair-create failed as same 'ingress' and 'egress' port is in
use. Thus ppg also can't be created.

So, we can't create a new ppg (with same details) neither can we reuse,
which restrict the reverse path creation by user.

What is the correct solution to achieve same ? What is the implication
if we let the ppg reuse ??

-- 
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] [go][containers] Update on go-and-containers etherpad ideas

[Davanum Srinivas]

Team,

Update on the stuff we talked about in
https://etherpad.openstack.org/p/go-and-containers

* Golang consistent testing interface governance resolution is OK'ed
   (https://review.openstack.org/#/c/410355/)
* Golang client for OpenStack is picking up steam
   (https://review.openstack.org/#/q/project:openstack/golang-client)
* Golang Commons library repository is ready and awaiting contributors
   (https://review.openstack.org/#/q/project:openstack/golang-commons)
* Docker Machine Driver for OpenStack repo is ready and things are working
   (https://review.openstack.org/#/q/project:openstack/docker-machine-openstack)
   - Able to run docker-machine command line and use the driver to
deploy docker in a VM running in OpenStack)
   - Working on ability to run Kubernetes minikube which also can
reuse the docker drivers, first we have to fix minikube to run against
external drivers
 (https://github.com/kubernetes/minikube/pull/1275)

Need help and volunteers for all the things! Join us on #openstack-golang

Thanks,
Dims


-- 
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][ui] [heat] i18n proposal for heat templates 'description' help strings

[Thomas Herve]

On Thu, Mar 23, 2017 at 9:39 AM, Peng Wu  wrote:
> Hi,
>
>   For TripleO UI project, some users requested to translate the web UI.
> But some web UI string are from heat template files in tripleo-heat-
> templates project.
>
>   In order to get translated templates displayed in tripleo-ui, we
> propose a blueprint as follows, which needs to change code in heat,
> tripleo-heat-tempates and tripleo-ui projects.
>
>   I18n proposal for heat templates 'description' help strings
>
>   1. Update heat project to accept "translation-domain" header in
> RESTful request, like "translation-domain: tripleo-heat-templates"
>
>  a. With "translation-domain" header, heat will try to translate
> "title" and "description" field using "tripleo-heat-templates.po"
>
>  b. Without "translation-domain" header, heat will return the
> fields like before
>
>  c. Add some field in config file for security to have a list of
> allowed "translation-domain",
> like "allowed-translation-domains: ['tripleo-heat-templates',
> ...]"

>From the Heat side of things, that sounds like a big no-no to me.
While we've done many things to cater to TripleO, this is way too
specific of a use case. It doesn't even make sense for the general use
case of passing user templates to Heat.


>   2. Update tripleo-heat-templates to generate the translation files,
>  like "tripleo-heat-templates.pot"
>
>  a. May need to write python script to extract "title" and
> "description" field from yaml files
>
>  b. May need to integrate into python babel config or use separate
> po files
>
>
>   3. Update tripleo-ui to use locale API with "translation-domain"
> header to ask the RESTful response with translated "title" and
> "description" fields from heat services
>
>  a. tripleo-ui will send request with two additional headers:
> "Accept-Language" and "translation-domain: tripleo-heat-
> templates"

Those last 2 steps may make more sense. Possibly try to store those
translation files somewhere and manage them in the UI?

Thanks,

-- 
Thomas

__
OpenStack Development Mailing 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] Arrivederci

[Thierry Carrez]

Ian Cordasco wrote:
> Friday 24 March 2017 will be my last day working on OpenStack.

We'll certainly miss you! You truly understood the benefits and
challenges of open collaboration, and I really appreciated your insights
on how to follow and preserve our 4 opens.

I'm certain OpenStack will touch enough adjacent communities in the
future that our paths will meet again.

Arrivederci!

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [tripleo][ui] [heat] i18n proposal for heat templates 'description' help strings

[Peng Wu]

Hi,

  For TripleO UI project, some users requested to translate the web UI.
But some web UI string are from heat template files in tripleo-heat-
templates project.

  In order to get translated templates displayed in tripleo-ui, we
propose a blueprint as follows, which needs to change code in heat,
tripleo-heat-tempates and tripleo-ui projects.

  I18n proposal for heat templates 'description' help strings

  1. Update heat project to accept "translation-domain" header in
RESTful request, like "translation-domain: tripleo-heat-templates"

 a. With "translation-domain" header, heat will try to translate
"title" and "description" field using "tripleo-heat-templates.po"

 b. Without "translation-domain" header, heat will return the
fields like before

 c. Add some field in config file for security to have a list of
allowed "translation-domain",
like "allowed-translation-domains: ['tripleo-heat-templates',
...]"

  2. Update tripleo-heat-templates to generate the translation files,
 like "tripleo-heat-templates.pot"

 a. May need to write python script to extract "title" and
"description" field from yaml files

 b. May need to integrate into python babel config or use separate
po files


  3. Update tripleo-ui to use locale API with "translation-domain"
header to ask the RESTful response with translated "title" and
"description" fields from heat services

 a. tripleo-ui will send request with two additional headers:
"Accept-Language" and "translation-domain: tripleo-heat-
templates"

  Please evaluate it, thanks!

Regards,
  Peng

__
OpenStack Development Mailing 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] [User-committee] Boston Forum - Formal Submission Now Open!

[Thierry Carrez]

Eoghan Glynn wrote:
> Thanks for putting this together!
> 
> But one feature gap is some means to tag topic submissions, e.g.
> tagging the project-specific topics by individual project relevance.
> That could be a basis for grouping topics, to allow folks to better
> manage their time during the Forum.
> 
> (e.g. if someone was mostly interested in say networking issues, they
> could plan to attend all the neutron- and kuryr-tagged topics more
> easily if those slots were all scheduled in a near-contiguous block
> with minimal conflicts)

That is a good point! The tooling we are using this time is pretty basic
(a resurrection of good old odsreg for submission / selection, with
manual scheduling to the summit scheduling system in the end), and we'll
certainly improve it for future Forums.

For this first one, we'll likely rely on the Forum selection committee
to add the relevant tags when they manually schedule the session. It's
probably doable since there are a lot less sessions (only 3 parallel
Forum rooms * 4 days compared to the ~20 * 5 we had in "Design Summits").

So if you have specific attendance needs that should be tagged in a
session, I encourage you to mention it in the description, for them to
pick it up at scheduling time. Also, once the schedule is up, if you see
a missing tag, feel free to reach out to them so that they add it.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] Is there some way to run specific unittest in neutron?

[Sam]

Thank you all

2017-03-23 13:41 GMT+08:00 Kevin Benton :

> tox -epy27 test_ovs_neutron_agent
>
> On Mar 22, 2017 22:25, "Sam"  wrote:
>
>> Hi all,
>>
>> I'm working on neutron, I add some code into ovs_neutron_agent.py, and I
>> extend test_ovs_neutron_agent.py.
>>
>> Is there some way to run test_ovs_neutron_agent.py or run related module
>> only?
>>
>> Thank you.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Using mistral to start a not-to-die task

[Renat Akhmerov]

Another option:

1. Run a workflow with a loop (i.e. task calls itself), in order to have a 
delay between task executions you can use either wait-before/wait-after task 
policies
2.a The workflow can be stopped via Mistral API by a 3rd party, if needed.
2.b The workflow can have a special task that checks if it still needs to be 
running (i.e. making a request to a 3rd party), it can be done using 
conditional transitions


Renat Akhmerov
@Nokia

> On 23 Mar 2017, at 09:40, Lingxian Kong  wrote:
> 
> Yeah, as Bob said, cron-trigger is what you are looking for.
> 
> As our discussion on IRC, currently, Mistral doesn't support to execute shell 
> command directly, my suggestion is, you could consider using http action 
> (which is supproted by Mistral out of the box) or providing a host (physical 
> or virtual) to run 'ping' command and use ssh action in Mistral.
> 
> 
> Cheers,
> Lingxian Kong (Larry)
> 
> On Thu, Mar 23, 2017 at 1:16 PM, gongys2017  > wrote:
> Hi mistral stackers,
> 
> Tacker is using the mistral as its part of system. Now we have a requirement:
> 
> tacker server registers an openstack as its NFVI, and needs to ping http-ping) the openstack's management IP,
> for example the keystone URL until tacker updates or delete the openstack 
> NFVI.
> 
> Can the mistral be asked to start a workflow which  contains  just such a 
> kind of task:
> for ever running until extenal tells him to stop.
> 
> 
> Thanks
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing 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] [QA] Meeting Thursday Mar 23rd at 9:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Mar 23rd at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_March_23rd_2017_.280900_UTC.29


Anyone is welcome to add an item to the agenda.
-gmann
__
OpenStack Development Mailing 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] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

Hi folks,

I've completed the work in Horizon space
(https://review.openstack.org/#/c/444095/) but I've just tried to run
up a devstack with searchlight enabled to test the searchlight-ui side
and put together a patch there, but the devstack plugin for
searchlight appears to be broken at the moment (I think because of bug
https://bugs.launchpad.net/searchlight/+bug/1648255).


 Richard


On 14 March 2017 at 09:43, Richard Jones  wrote:
> I'll definitely be looking at getting a searchlight-ui patch up for
> the mirror side of my Horizon patch.
>
> Double registration largely depends on which particular aspect of the
> resource type is being looked at. Most of the resource type
> registration will just be replaced (with identical information) but
> the kicker will be table columns and actions which are added by append
> (via extensible service), so they'll all be duplicated if both
> registrations run. So ideally both searchlight-ui and Horizon would be
> updated at the same time.
>
>
>  Richard
>
> On 11 March 2017 at 04:34, Tripp, Travis S  wrote:
>> Hi Richard,
>>
>> I’m headed out for vacation so won’t be able to look through it until I get 
>> back.  However, can you also please get an install of searchlight-ui running 
>> so that you can see if anything breaks?  I know you don’t typically use 
>> devstack, but the searchlight devstack plugin installs searchlight UI. [0]
>>
>> The one thing I’m not sure about is how the resource registry handles 
>> potential double registrations.  So, if the resource is registered both code 
>> bases, I don’t know what would get loaded.
>>
>> https://review.openstack.org/#/c/444095/2/openstack_dashboard/static/app/core/instances/instances.module.js
>> https://github.com/openstack/searchlight-ui/blob/master/searchlight_ui/static/resources/os-nova-servers/os-nova-servers.module.js#L57
>>
>> [0] https://github.com/openstack/searchlight/tree/master/devstack
>>
>> Thanks,
>> Travis
>>
>> On 3/9/17, 10:58 PM, "Richard Jones"  wrote:
>>
>> Thanks, Steve!
>>
>> I've put together an initial patch
>> https://review.openstack.org/#/c/444095/ which pulls in the
>> os-nova-servers module and a little extra to make it work in Horizon's
>> codebase. I've tried to make minimal edits to the actual code -
>> predominantly just editing module names. I've tested it and it mostly
>> works on Horizon's side \o/
>>
>>
>>  Richard
>>
>> On 10 March 2017 at 14:40, McLellan, Steven  
>> wrote:
>> > My expertise in this area is deeply suspect but as long as we maintain 
>> the
>> > mapping from the resource type names that searchlight uses 
>> (os-nova-servers)
>> > to the modules we'll be OK. If you or Rob put a patch up against 
>> horizon I
>> > (or a willing victim/volunteer) can test a searchlight-ui patch 
>> against it.
>> >
>> >
>> >  Original message 
>> > From: Richard Jones 
>> > Date: 3/9/17 21:13 (GMT-06:00)
>> > To: "OpenStack Development Mailing List (not for usage questions)"
>> > 
>> > Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource 
>> type
>> > implementations
>> >
>> > Hey folks,
>> >
>> > Another potential issue is that the searchlight module structure and
>> > Horizon's module structure are different in a couple of respects. I
>> > could just retain the module structure from searchlight
>> > ('resources.os-nova-servers') or, preferably, I could rename those
>> > modules to match the Horizon structure more closely
>> > ('horizon.app.resources.os-nova-servers') or more strictly
>> > ('horizon.app.core.instances').
>> >
>> > As far as I can tell none of the module names are referenced directly
>> > outside of the module (apart from resources.module.js of course) so
>> > moving the modules shouldn't affect any existing usage in searchlight
>> > ui.
>> >
>> > We could bikeshed this for ages, so if I could just get Rob and Steve
>> > to wrestle over it or something, that'd be good. Rob's pretty scrappy.
>> >
>> >
>> >   Richard
>> >
>> >
>> > On 10 March 2017 at 09:56, Richard Jones  
>> wrote:
>> >> OK, I will work on a plan that migrates the code into Horizon, thanks
>> >> everyone!
>> >>
>> >> Travis, can the searchlight details page stuff be done through
>> >> extending the base resource type in Horizon? If not, is that perhaps a
>> >> limitation of the extensible service?
>> >>
>> >>
>> >>  Richard
>> >>
>> >>
>> >> On 10 March 2017 at 02:20, McLellan, Steven 
>> >> wrote:
>> >>> I concur; option 4 is the only one makes sense to me and was what was
>> >>> intended originally. As