[openstack-dev] [QA] Meeting Thursday Mar 9th at 9:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Mar 9th 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_9th_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

[openstack-dev] [kolla] Proposing duonghq for core

[Michał Jastrzębski]

Hello,

I'd like to start voting to include Duong (duonghq) in Kolla and
Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
21st of March).

Consider this my +1 vote.

Cheers,
Michal

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

Re: [openstack-dev] Disabling glance v1 by default in devstack

[Nikhil Komawar]

Thanks Matt. Yes please, lets all start getting rid of glance v1 in our
tests and then on..

On 3/3/17 2:35 PM, Matt Riedemann wrote:
> I've got a change proposed to disable glance v1 by default in devstack
> for Pike [1].
>
> The glance v1 API has been deprecated for awhile now. Nova started
> supporting glance v2 in Newton and removed the ability to use nova
> with glance v1 in Ocata.
>
> It also turns out that Tempest will do things with glance v1 over v2
> during test setup of glance v1 is available, so we're missing out on
> some v2 coverage.
>
> The time has come to change the default. If you have a project or CI
> jobs that require glance v1, first, you should probably start moving
> to v2, and second, you can re-enable this by setting
> GLANCE_V1_ENABLED=True in the settings/localrc for your devstack plugin.
>
> [1] https://review.openstack.org/#/c/343129/
>

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing 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] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Hi Igor,

   This is weird. I just did a fresh clone and executed *"tox" *command. I
am getting same error. Am I missing anything here ? There is no private
change here.  Below is the link for entire log.

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

On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi Vikash,
>
> Please stick to pastebin for complete logs.
>
>
>
> Check your migration files:
>
>
>
> FAILED: Contract HEAD file does not match migration timeline head,
> expected: 48072cb59133
>
>
>
> Best regards,
>
> Igor.
>
>
>
> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
> *Sent:* Tuesday, March 7, 2017 5:03 PM
> *To:* openstack-dev 
> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
> "import error: vlanmanager"
>
>
>
> Complete log:
>
>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
> py35 installdeps: 
> -r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt,
> -r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
> py35 installed: 
> /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,
> anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,
> beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,
> cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==
> 4.3.4,cryptography==1.7.2,debtcollector==1.12.0,
> decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet=
> =0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.
> 0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking=
> =0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601=
> =0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,
> keystoneauth1==2.18.0,keystonemiddleware==4.14.0,
> kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,
> logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.
> 1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==
> 0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e git+https://github.com/
> openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc2
> 0d2e484490#egg=networking_sfc,-e git+https://github.com/
> openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a
> 72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,
> openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==
> 1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==
> 3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==
> 4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.
> 18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.
> reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.
> 17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.
> versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==
> 2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.
> 0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,
> pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable=
> =0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.
> 5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,
> pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==
> 2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,
> python-designateclient==2.6.0,python-editor==1.0.3,python-
> glanceclient==2.6.0,python-keystoneclient==3.10.0,python-
> mimeparse==1.6.0,python-neutronclient==6.1.0,python-
> novaclient==7.1.0,python-openstackclient==3.8.1,python-
> subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,
> repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,
> requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.
> 1,Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.
> 0,snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.
> 17,sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,
> stevedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==3.7.1,
> testrepository==0.0.20,testresources==2.0.1,testscenarios==0.5.0,
> testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.0,unittest2==
> 1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.6.3,WebTest==
> 2.0.26,wrapt==1.10.8
> py35 runtests: PYTHONHASHSEED='177840'
> py35 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
> py35 runtests: commands[1] | find . -type d -name __pycache__ -delete
> py35 runtests: commands[2] | /home/vikash/guess_vk/python-
> dev/networking-sfc/tools/ostestr_compat_shim.sh
> /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
> DeprecationWarning: 'U' mode is deprecated
>   f = open(fullname, "rU")
> /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
> DeprecationWarning: 'U' mode is deprecated
>   f = open(fullname, "rU")
> /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
> DeprecationWarning: 

Re: [openstack-dev] Disabling glance v1 by default in devstack

[Ghanshyam Mann]

On Sat, Mar 4, 2017 at 6:01 AM, Andrea Frittoli 
wrote:

>
>
> On Fri, Mar 3, 2017 at 7:38 PM Matt Riedemann  wrote:
>
>> I've got a change proposed to disable glance v1 by default in devstack
>> for Pike [1].
>>
>> The glance v1 API has been deprecated for awhile now. Nova started
>> supporting glance v2 in Newton and removed the ability to use nova with
>> glance v1 in Ocata.
>>
>> It also turns out that Tempest will do things with glance v1 over v2
>> during test setup of glance v1 is available, so we're missing out on
>> some v2 coverage.
>>
> +1. We should really test v2 as opposed to v1.
>

​+1, we have lot of if else and coverage issue by having both version in
tempest.
First step with deprecation on config options. -
https://review.openstack.org/#/c/442939/1




>
>
>>
>> The time has come to change the default. If you have a project or CI
>> jobs that require glance v1, first, you should probably start moving to
>> v2, and second, you can re-enable this by setting GLANCE_V1_ENABLED=True
>> in the settings/localrc for your devstack plugin.
>>
>> [1] https://review.openstack.org/#/c/343129/
>>
>> --
>>
>> 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 Development Mailing 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] [telemetry][requirements] ceilometer grenade gate failure

[Tony Breeds]

On Wed, Mar 08, 2017 at 03:16:29AM +, gordon chung wrote:
> hi,
> 
> this is just an fyi but i've proposed a fix[1] for ceilometer grenade 
> gate failures we have.
> 
> i've added reasoning in commit message but to re-iterate, 
> ceilometermiddleware never gets bumped to master upper-constraint 
> because it's not in any projects requirements and is conditionally 
> installed by devstack. therefore, in grenade, the base(ocata) install 
> will have oslo.messaging==5.17.1 and ceilometermiddleware==1.0.0 which 
> works fine. the upgraded(master) install will bump 
> oslo.messaging==5.18.0 but ceilometermiddleware stays at 1.0.0 which is 
> not fine as a deprecated kwarg was dropped.
> 
> the proposal is to just bump ocata ceilometermiddleware upperconstraint 
> to 1.0.1 as it is compatible with oslo.messaging from master, ocata, and 
> newton (and maybe mitaka).
> 
> hope this answers any questions and is cool with everyone.

Sure.

I've approved it but it's blocked behind 
https://review.openstack.org/#/c/442886/1

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] [tc][appcat][murano][app-catalog] The future of the App Catalog

[Christopher Aedo]

On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez  wrote:
> Hello everyone,
>
> The App Catalog was created early 2015 as a marketplace of pre-packaged
> applications that you can deploy using Murano. Initially a demo by
> Mirantis, it was converted into an open upstream project team, and
> deployed as a "beta" as apps.openstack.org.
>
> Since then it grew additional categories (Glance images, Heat & Tosca
> templates), but otherwise did not pick up a lot of steam. The website
> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> heat templates and 94 murano packages (~30% of which are just thin
> wrappers around Docker containers). Traffic stats show around 100 visits
> per week, 75% of which only read the index page.
>
> In parallel, Docker developed a pretty successful containerized
> application marketplace (the Docker Hub), with hundreds of thousands of
> regularly-updated apps. Keeping the App Catalog around (including its
> thinly-wrapped Docker container Murano packages) make us look like we
> are unsuccessfully trying to compete with that ecosystem, while
> OpenStack is in fact completely complementary.

Without something like Murano "thinly wrapping" docker apps, how would
you propose current users of OpenStack clouds deploy docker apps?  Or
any other app for that matter?  It seems a little unfair to talk about
murano apps this way when no reasonable alternative exists for easily
deploying docker apps.  When I look back at the recent history of how
we've handled containers (nova-docker, magnum, kubernetes, etc) it
does not seem like we're making it easy for the folks who want to
deploy a container on their cloud...

Please understand I am not pleading to keep the Community App Catalog
alive in perpetuity.  This just sounds like an unfair point of
comparison.  One of the biggest challenges we've faced with the app
catalog since day one is that there is no such thing as a simple
definition of an "OpenStack Application".  OpenStack is an IaaS before
anything else, and to my knowledge there is no universally accepted
application deployment mechanism for OpenStack clouds.  Heat doesn't
solve that problem as its very operator focused, and while being very
popular and used heavily, it's not used as a way to share generic
templates suitable for deploying apps across different clouds.  Murano
is not widely adopted (last time I checked it's not available on any
public clouds, though I hear it is actually used on a several
university clouds, and it's also used on a few private clouds I'm
aware of.)

As a place to find things that run on OpenStack clouds, the app
catalog did a reasonable job.  If anything, the experiment showed that
there is no community looking for a place to share OpenStack-specific
applications.  There are definitely communities for PaaS layers (cloud
foundry, mesosphere, docker, kubernetes), but I don't see any
community for openstack-native applications that can be deployed on
any cloud, nor a commonly accepted way to deploy them.

> In the past we have retired projects that were dead upstream. The App
> Catalog is not in this case: it has an active maintenance team, which
> has been successfully maintaining the framework and accepting
> applications. If we end up retiring the App Catalog, it would clearly
> not be a reflection on that team performance, which has been stellar
> despite limited resources. It would be because the beta was arguably not
> successful in building an active marketplace of applications, and
> because its continuous existence is not a great fit from a strategy
> perspective. Such removal would be a first for our community, but I
> think it's now time to consider it.
>
> Before we discuss or decide anything at the TC level, I'd like to
> collect everyone thoughts (and questions) on this. Please feel free to
> reply to this thread (or reach out to me privately if you prefer). Thanks !

As the former PTL I am obviously a little bit biased.  Even though my
focus has shifted and I've stepped away from the app catalog, I had
been spending a lot of time trying to figure out how to make
applications an easy to run thing on OpenStack.  I've also been trying
to find a community of people who are looking for that, and it doesn't
seem like they've materialized; possibly because that community
doesn't exist?  Or else we just haven't been able to figure out where
they're hiding ;)

The one consideration that is pretty important here is what this would
mean to the Murano community.  Those folks have been contributed time
and resources to the app catalog project.  They've also standardized
on the app catalog as the distribution mechanism, intending to make
the app catalog UI a native component for Murano. We do need to make
sure that if the app catalog is retired, it doesn't hamper or impact
people who have already deployed Murano and are counting on finding
the apps in the app catalog.

-Christopher

>
> --
> Thierry Carrez (ttx)
>
> 

[openstack-dev] [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud archive ocata repo bust

[Jeffrey Zhang]

Kolla deploy ubuntu gate is red now. here is the related bug[0].

libvirt failed to access the console.log file when booting instance. After
made some debugging, i got following.

# how console.log works
nova create a empty console.log with nova:nova ( this is another bug
workaround actually[1]), then libvirt ( running with root ) will change the
file owner to qemu process user/group ( configured by dynamic_ownership ).
Now qemu process can write logs into this file.

# what's wrong now
libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to write
logs into console.log file

# other test

* ubuntu + fallback libvirt 1.3.x works [2]
* ubuntu + libvirt 2.5.0 + chang the qemu process user/group to
  nova:nova works, too.[3]
* centos + libvirt 2.0.0 works, never saw such issue in centos.

# conclusion
I guess there are something wrong in libvirt 2.5.0 with dynamic_ownership


[0] https://bugs.launchpad.net/kolla-ansible/+bug/1668654
[1]
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2922,L2952
[2] https://review.openstack.org/442673
[3] https://review.openstack.org/442850

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

[openstack-dev] [telemetry][requirements] ceilometer grenade gate failure

[gordon chung]

hi,

this is just an fyi but i've proposed a fix[1] for ceilometer grenade 
gate failures we have.

i've added reasoning in commit message but to re-iterate, 
ceilometermiddleware never gets bumped to master upper-constraint 
because it's not in any projects requirements and is conditionally 
installed by devstack. therefore, in grenade, the base(ocata) install 
will have oslo.messaging==5.17.1 and ceilometermiddleware==1.0.0 which 
works fine. the upgraded(master) install will bump 
oslo.messaging==5.18.0 but ceilometermiddleware stays at 1.0.0 which is 
not fine as a deprecated kwarg was dropped.

the proposal is to just bump ocata ceilometermiddleware upperconstraint 
to 1.0.1 as it is compatible with oslo.messaging from master, ocata, and 
newton (and maybe mitaka).

hope this answers any questions and is cool with everyone.

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

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] [all] Some information about the Forum at the Summit in Boston

[Tom Fifield]

On 廿十七年三月七日 暮 11:26, Matt Riedemann wrote:

On 3/7/2017 6:35 AM, Thierry Carrez wrote:

Hi everyone,

I recently got more information about the space dedicated to the "Forum"
at the OpenStack Summit in Boston. We'll have three different types of
spaces available.

1/ "Forum" proper

There will be 3 medium-sized fishbowl rooms for cross-community
discussions. Topics for the discussions in that space will be selected
and scheduled by a committee formed of TC and UC members, facilitated by
Foundation staff members. In case you missed it, the brainstorming for
topics started last week, announced by Emilien in that email:

http://lists.openstack.org/pipermail/openstack-dev/2017-March/113115.html

2/ "On-boarding" rooms

We'll have two rooms set up in classroom style, dedicated to project
teams and workgroups who want to on-board new team members. Those can
for example be booked by project teams to run an introduction to their
codebase to prospective new contributors, in the hope that they will
join their team in the future. Those are not meant to do traditional
user-facing "project intro" talks -- there is space in the conference
for that. They are meant to provide the next logical step in
contributing after Upstream University and being involved on the
sidelines. It covers the missing link for prospective contributors
between attending Summit and coming to the PTG. Kendall Nelson and Mike
Perez will soon announce the details for this, including how projects
can sign up.

3/ Free hacking/meetup space

We'll have four or five rooms populated with roundtables for ad-hoc
discussions and hacking. We don't have specific plans for these -- we
could set up something like the PTG ethercalc for teams to book the
space, or keep it open. Maybe half/half.

More details on all this as they come up.
Hoping to see you there !



Thanks for the details, this helps.

Any idea what the breakdown in days are going to be, like "Forum"
sessions are Monday/Tuesday or Tuesday/Wednesday, or are they all four
days?


Probably all four days.


The nova people that are going to be there would like to take advantage
of the face-to-face time to work on some of the priority items for the
Pike release in the free hacking/meetup space but without knowing when
the other sessions are going to be it's hard to know when we can
schedule space in the hacking pit.

If that's all TBD that's fair, I just wanted to ask.



__
OpenStack Development Mailing 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] [glance] image import sync tomorrow CANCELLED

[Brian Rosmaita]

The Glance image import sync scheduled for 16:00 UTC on 8 March 2017 is
postponed until next week.  More details at the regular Glance weekly
meeting on Thursday.

cheers,
brian


On 3/7/17 9:49 AM, Brian Rosmaita wrote:
> Sorry for the late notice, but we'll be having a one-hour image import
> sync via video conference at 16:00 UTC tomorrow (8 March 2017).
> 
> Watch the ML for more details later today, plus connection info will be
> posted in #openstack-glance around 15:45 UTC tomorrow.
> 
> cheers,
> brian
> 


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

Re: [openstack-dev] [TripleO][Heat] Selectively disabling deployment resources

[Zane Bitter]

On 07/03/17 14:34, James Slagle wrote:

I've been working on this spec for TripleO:
https://review.openstack.org/#/c/431745/

which allows users to selectively disable Heat deployment resources
for a given server (or server in the case of a *DeloymentGroup
resource).


I'm not completely clear on what this means. You can selectively disable 
resources with conditionals. But I think you mean that you want to 
selectively disable *changes* to resources?



Some of the main use cases in TripleO for such a feature are scaling
out compute nodes where you do not need to rerun Puppet (or make any
changes at all) on non-compute nodes, or to exclude nodes from hanging
a stack-update if you know they are unreachable or degraded for some
reason. There are others, but those are 2 of the major use cases.


I think you're running up against a limitation of the scaling group 
implementation in Heat. In AWS Autoscaling, you have a LaunchConfig 
associated with a group that is used when scaling up to create new 
members, but existing members are not changed when you specify a new 
LaunchConfig unless you also specifically include a rolling update 
UpdatePolicy. (That isn't a great interface in CloudFormation, but it 
works and I can't actually think of anything better.)


Heat's AWS-style resources work similarly. Heat's native autoscaling 
group resources don't have a separate LaunchConfig, and although they 
used to work similarly to the AWS ones with respect to when they would 
update existing members, IIRC somebody decided that was a "bug" and 
"fixed" it.


In any event, TripleO uses ResourceGroup, and the very existence of 
ResourceGroup is predicated on the idea that you can just generate the 
nested template by making copies of the inline resource definition - 
that is, the idea that you'll *never* need this feature which it turns 
out you do, in fact, need. TripleO can't move away from ResourceGroup 
because it relies on it to auto-assign pre-chosen names for specific 
servers.


Senlin, for the record, gets this right.


I started by taking an approach that would be specific to TripleO.
Basically mapping all the deployment resources to a nested stack
containing the logic to selectively disable servers from the
deployment (using yaql) based on a provided parameter value. Here's
the main patch: https://review.openstack.org/#/c/442681/

After considering that complexity, particularly the yaql expression,
I'm wondering if it would be better to add this support natively to
Heat.

I was looking at the restricted_actions key in the resource_registry
and was thinking this might be a reasonable place to add such support.
It would require some changes to how restricted_actions work.

One change would be a method for specifying that restricted_actions
should not fail the stack operation if an action would have otherwise
been triggered. Currently the behavior is to raise an exception and
mark the stack failed if an action needs to be taken but has been
marked restricted. That would need to be tweaked to allow specifying
that that we don't want the stack to fail. One thought would be to
change the allowed values of restricted_actions to:

replace_fail
replace_ignore
update_fail
update_ignore
replace
update

where replace and update were synonyms for replace_fail/update_fail to
maintain backwards compatibility.


Anything that involves the resource definition in the template changing 
but Heat not modifying the resource is problematic, because that messes 
with Heat's internal bookkeeping.



Another change would be to add logic to the Deployment resources
themselves to consider if any restricted_actions have been set on an
Server resources before triggering an updated deployment for a given
server.


Why not just a property, "no_new_deployments_please: true"?


It also might be nice to allow specifying restricted_actions on the
server's name property (which typically is the hostname) instead of
having to use the resource name. The reason being is that it is not
really feasibly to expect operators/users to have to represent the
full nested_stack structure in their resource_registry. They would
have to query and record nested_stack names just to refer to a given
server resource. Each ResourceGroup nested stack would be have to be
individually represented, etc. Unless there is another way I'm
overlooking.

Whether or not the restricted_actions approach is taken, is Heat
interested in this functionality natively? I think it would make for a
much cleaner implementation than something TripleO specific. I can
work on a Heat spec if there's interest, though I'd like to get some
early feedback.

Thanks.




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

[openstack-dev] [congress] meeting topics

[Eric K]

Hi all,

Proposed topics for the next congress irc meeting are tracked in this
etherpad: https://etherpad.openstack.org/p/congress-meeting-topics
Feel free to add additional topics and/or comment on existing ones. Thanks!



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

Re: [openstack-dev] A Summary of Atlanta PTG Summaries (!)

[Emilien Macchi]

On Mon, Mar 6, 2017 at 10:45 PM, Hugh Blemings  wrote:
> Hiya,
>
> As has been done for the last few Summits/PTGs in Lwood[1] I've pulled
> together a list of the various posts to openstack-dev that summarise things
> at the PTG - projects, videos, anecdotes etc.
>
> The aggregated list is in this blog post;
>
> http://hugh.blemings.id.au/2017/03/07/openstack-ptg-atlanta-2017-summary-of-summaries/
>
> Which should aggregate across to planet.openstack.org as well.
>
> I'll update this as further summaries appear, corrections/contributions
> welcome.

Thanks Hugh, that's awesome!
Can you please remove the first link: TripleO:
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112893.html
and only keep this one:
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112995.html

Thanks a lot!

> Cheers,
> Hugh
>
> [1] http://hugh.blemings.id.au/openstack/lwood/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

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

[openstack-dev] [congress] Pike tasks

[Eric K]

Hi all,

Based on our discussions at the PTG, I have set up some tasks for Pike.
https://bugs.launchpad.net/congress/+bugs?field.tag=pike-goal

Feel free to adjust them (text, priority, target, assignee, etc.) or suggest
changes as you see fit.


__
OpenStack Development Mailing 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][tripleo][fuel][kolla][ansible] Ocata Release countdown for R+2 Week, 6-10 March

[Vladimir Kuklin]

Doug

I have proposed the change for Fuel RC2 [0], but it has W-1 set as I am
waiting for the final tests result. If everything goes alright, I will
check the Worfklow off and this RC2 can be the cut as the release.

[0] https://review.openstack.org/#/c/442775/

On Tue, Mar 7, 2017 at 3:39 AM, Jeffrey Zhang 
wrote:

> Sorry for late. But Kolla project need a new release candidate. I will
> push it today.
>
> On Tue, Mar 7, 2017 at 6:27 AM, Doug Hellmann 
> wrote:
>
>> Excerpts from Doug Hellmann's message of 2017-03-06 11:00:15 -0500:
>> > Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500:
>> > >
>> > > Release Tasks
>> > > -
>> > >
>> > > Liaisons for cycle-trailing projects should prepare their final
>> > > release candidate tags by Monday 6 March. The release team will
>> > > prepare a patch showing the final release versions on Wednesday 7
>> > > March, and PTLs and liaisons for affected projects should +1. We
>> > > will then approve the final releases on Thursday 8 March.
>> >
>> > We have 13 cycle-trailing deliverables without final releases for Ocata.
>> > All have at least one release candidate, so if no new release candidates
>> > are proposed *today* I will prepare a patch using these versions as the
>> > final and we will approve that early Wednesday.
>> >
>> > If you know that you need a new release candidate, please speak up now.
>> >
>> > If you know that you do not need a new release candidate, please also
>> > let me know that.
>> >
>> > Thanks!
>> > Doug
>> >
>> > $ list-deliverables --series ocata --missing-final -v
>> > fuel   fuel 11.0.0.0rc1 other
>>  cycle-trailing
>> > instack-undercloud tripleo  6.0.0.0rc1 other
>>cycle-trailing
>> > kolla-ansible  kolla4.0.0.0rc1 other
>>cycle-trailing
>> > kolla  kolla4.0.0.0rc1 other
>>cycle-trailing
>> > openstack-ansible  OpenStackAnsible 15.0.0.0rc1 other
>>  cycle-trailing
>> > os-apply-configtripleo  6.0.0.0rc1 other
>>cycle-with-milestones
>> > os-cloud-configtripleo  6.0.0.0rc1 other
>>cycle-with-milestones
>> > os-collect-config  tripleo  6.0.0.0rc1 other
>>cycle-with-milestones
>> > os-net-config  tripleo  6.0.0.0rc1 other
>>cycle-with-milestones
>> > os-refresh-config  tripleo  6.0.0.0rc1 other
>>cycle-with-milestones
>> > tripleo-heat-templates tripleo  6.0.0.0rc1 other
>>cycle-trailing
>> > tripleo-image-elements tripleo  6.0.0.0rc1 other
>>cycle-trailing
>> > tripleo-puppet-elementstripleo  6.0.0.0rc1 other
>>cycle-trailing
>> >
>>
>> I have lined up patches with the final release tags for all 3 projects.
>> Please review and +1 or propose a new patch with an updated release
>> candidate.
>>
>> Ansible: https://review.openstack.org/442138
>> Kolla: https://review.openstack.org/442137
>> TripleO: https://review.openstack.org/442129
>>
>> Doug
>>
>> 
>> __
>> 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
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
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] [Neutron] ImportError: No module named neutron_lib

[Tony Breeds]

On Tue, Mar 07, 2017 at 04:04:55PM +0800, Sam wrote:
> Is this?
> 
> https://pypi.python.org/pypi/neutron-lib

Make sure you're installing with upper-constratints otehrwise you'll get
components that rely on features for newer releases

Assuming you're installing with pip something like[1]

wget 'http://tarballs.openstack.org/neutron/neutron-8.4.0-py2.py3-none-any.whl'
wget 
'http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/mitaka'

pip install -c upper-constratints.txt ./neutron-8.4.0-py2.py3-none-any.whl

Should get you a stable/mitaka neutron with appropriate versions of all
libraries in use.

Yours Tony.

[1] You may be able to pass the URLs directly to pip but I haven't tested that 
for wheels


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] [QA][blazar][ceilometer][congress][intel-nfv-ci-tests][ironic][manila][networking-bgpvpn][networking-fortinet][networking-sfc][neutron][neutron-fwaas][neutron-lbaas][nova-lxd][octa

[Andrea Frittoli]

Hi,

an update on this.

It's about 10days since the original message, and the current status is:
- 3 patches merged, 1 approved (recheck)
- 5 patches submitted, pending approval
- 2 patches with a -1 (need more work)
- 7 patches submitted by me today (draft) - review needed

Thank you for your work on this!

I would recommend to prune the imported module as much as possible as well.
It would make it easier for the QA team to identify which interfaces on
Tempest side should be migrated to stable.

andrea

On Wed, Mar 1, 2017 at 1:25 PM Andrea Frittoli 
wrote:

> On Wed, Mar 1, 2017 at 2:21 AM Takashi Yamamoto 
> wrote:
>
> hi,
>
> On Mon, Feb 27, 2017 at 8:34 PM, Andrea Frittoli
>  wrote:
> > Hello folks,
> >
> > TL;DR: if today you import manager,py from tempest.scenario please
> maintain
> > a copy of [0] in tree until further notice.
> >
> > Full message:
> > --
> >
> > One of the priorities for the QA team in the Pike cycle is to refactor
> > scenario tests to a sane code base [1].
> >
> > As they are now, changes to scenario tests are difficult to develop and
> > review, and failures in those tests are hard to debug, which is in many
> > directions far away from where we need to be.
> >
> > The issue we face is that, even though tempest.scenario.manager is not
> > advertised as a stable interface in Tempest, many project use it today
> for
> > convenience in writing their own tests. We don't know about dependencies
> > outside of the OpenStack ecosystem, but we want to try to make this
> refactor
> > a smooth experience for our uses in OpenStack, and avoid painful gate
> > breakages as much as possible.
> >
> > The process we're proposing is as follows:
> > - hold a copy of [0] in tree - in most cases you won't even have to
> change
> > your imports as a lot of projects use tempest/scenario in their code
> base.
> > You may decide to include the bare minimum you need from that module
> instead
> > of all of it. It's a bit more work to make the patch, but less un-used
> code
> > lying around afterwards.
>
> i submitted patches for a few repos.
>
> https://review.openstack.org/#/q/status:open++branch:master+topic:tempest-manager
> i'd suggest to use the same gerrit topic for relevant patches.
>
> Thank you for looking into this!
> Having a common gerrit topic is a nice idea: "tempest-manager"
>
> I'm also tracking patches in this etherpad:
> https://etherpad.openstack.org/p/tempest-manager-plugins
>
> andrea
>
> > - the QA team will refactor scenario tests, and make more interfaces
> stable
> > (test.py, credential providers). We won't advertise every single change
> in
> > this process, only when we start and once we're done.
> > - you may decide to discard your local copy of manager.py and consume
> > Tempest stable interfaces directly. We will help with any question you
> may
> > have on the process and on Tempest interfaces.
> >
> > Repositories affected by the refactor are (based on [2]):
> >
> >
> blazar,ceilometer,congress,intel-nfv-ci-tests,ironic,manila,networking-bgpvpn,networking-fortinet,networking-sfc,neutron-fwaas,neutron-lbaas,nova-lxd,octavia,sahara-tests,tap-as-a-service,tempest-horizon,vmware-nsx,watcher
> >
> > If we don't hear from a team at all in the next two weeks, we will assume
> > that the corresponding Tempest plugin / bunch of tests is not in use
> > anymore, and ignore it. If you use tempest.scenario.manager.py today and
> > your repo is not on the list, please let us know!
> >
> > I'm happy to propose an initial patch for any team that may require it -
> > just ping me on IRC (andreaf).
> > I won't have the bandwidth myself to babysit each patch through review
> and
> > gate though.
> >
> > Thank you for your cooperation and patience!
> >
> > Andrea
> >
> > [0]
> >
> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/manager.py
> > [1] https://etherpad.openstack.org/p/pike-qa-priorities
> > [2]
> >
> https://github.com/andreafrittoli/tempest_stable_interfaces/blob/master/data/get_deps.sh
> >
> >
> __
> > OpenStack Development Mailing 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] [QA][blazar][ceilometer][congress][intel-nfv-ci-tests][ironic][manila][networking-bgpvpn][networking-fortinet][networking-sfc][neutron][neutron-fwaas][neutron-lbaas][nova-lxd][octa

[Andrea Frittoli]

Hi Pavlo,

thank you for your suggestion.
See my comments inline.

andrea
On Thu, Mar 2, 2017 at 9:19 AM Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi Andrea,
>
> I am not sure why the new tempest.scenario.manager has to be developed
> that way. May I humbly suggest another path? Roughly goes like:
>
> 1) Rename the present class to "OldScenarioTest", set the original name to
> point to it (ScenarioTest=OldScenarioTest) (in a single commit)
>

We considered a similar option [0], but I fear that maintaining the old
class in Tempest, and even gating on it, would just postpone the issue for
plugins, and would probably have the negative effect of making even more
plugin rely on that.


> 2) Create a new class NewScenarioTest (initially a copy of the old one?),
> development/refactoring/rewrite happens there, do not merge any new
> features in OldScenarioTest
>
> 3) add a tempest config option "USE_NEW_SCENARIO_MANAGER", False by default
>
> 4) conditionally on the value of USE_NEW_SCENARIO_MANAGER set the
> ScenarioTest to point to OldScenarioTest or NewScenarioTest
>
> 5) add a gate job(s) to tempest that forces USE_NEW_SCENARIO_MANAGER to
> True to test the new code, non-voting from the start, gate on it later
>

Having a gate job like this would make it really hard for us to get rid of
the it in future.


> This way the projects using tempest plugins and other tempest consumers
> will not be affected at all. Later each project on its jobs using tempest
> can try to enforce USE_NEW_SCENARIO_MANAGER to True if wishing to test the
> new one or switch to it when it is ready. Eventually when new one is
> stable, the config option might be removed and new class renamed to the
> name of the original class.
>
> The only downside of such approach I see might be a small? explosion of
> number of jobs in the tempest project (running on both new and old
> manager), but I'd think at least in the beginning of this refactoring
> effort the tempest team would like to have the number of jobs testing the
> new manager limited any way.
>
> I might be completely wrong with this advice, as I presume tempest team
> have put a lot of thinking into this problem already. But still, could you
> consider such approach?
>
>
Another option would be to:
- create a new base class in Tempest
- incrementally move scenario tests across to the new base class, along
with the helpers they need
However this would have the drawback of risking to break plugins again and
again, and to slow down the overall process.


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


> Cheers,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> On Mon, Feb 27, 2017 at 1:34 PM, Andrea Frittoli <
> andrea.fritt...@gmail.com> wrote:
>
> Hello folks,
>
> TL;DR: if today you import manager,py from tempest.scenario please
> maintain a copy of [0] in tree until further notice.
>
> Full message:
> --
>
> One of the priorities for the QA team in the Pike cycle is to refactor
> scenario tests to a sane code base [1].
>
> As they are now, changes to scenario tests are difficult to develop and
> review, and failures in those tests are hard to debug, which is in many
> directions far away from where we need to be.
>
> The issue we face is that, even though tempest.scenario.manager is not
> advertised as a stable interface in Tempest, many project use it today for
> convenience in writing their own tests. We don't know about dependencies
> outside of the OpenStack ecosystem, but we want to try to make this
> refactor a smooth experience for our uses in OpenStack, and avoid painful
> gate breakages as much as possible.
>
> The process we're proposing is as follows:
> - hold a copy of [0] in tree - in most cases you won't even have to change
> your imports as a lot of projects use tempest/scenario in their code base.
> You may decide to include the bare minimum you need from that module
> instead of all of it. It's a bit more work to make the patch, but less
> un-used code lying around afterwards.
> - the QA team will refactor scenario tests, and make more interfaces
> stable (test.py, credential providers). We won't advertise every single
> change in this process, only when we start and once we're done.
> - you may decide to discard your local copy of manager.py and consume
> Tempest stable interfaces directly. We will help with any question you may
> have on the process and on Tempest interfaces.
>
> Repositories affected by the refactor are (based on [2]):
>
>
> blazar,ceilometer,congress,intel-nfv-ci-tests,ironic,manila,networking-bgpvpn,networking-fortinet,networking-sfc,neutron-fwaas,neutron-lbaas,nova-lxd,octavia,sahara-tests,tap-as-a-service,tempest-horizon,vmware-nsx,watcher
>
> If we don't hear from a team at all in the next two weeks, we will assume
> that the corresponding Tempest plugin / bunch of tests is not in use
> anymore, and ignore it. If you use tempest.scenario.manager.py today and
> 

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Emilien Macchi]

On Mon, Feb 27, 2017 at 11:02 AM, Steven Hardy  wrote:
> Hi all,
>
> Over the recent PTG, and previously at the design summit in Barcelona,
> we've had some productive cross-project discussions amongst the various
> deployment teams.
>
> It's clear that we share many common problems, such as patterns for major
> version upgrades (even if the workflow isn't identical we've all duplicated
> effort e.g around basic nova upgrade workflow recently), container images
> and other common building blocks for configuration management.
>
> Here's a non-exhaustive list of sessions where we had some good
> cross-project discussion, and agreed a number of common problems where
> collaboration may be possible:
>
> https://etherpad.openstack.org/p/ansible-config-mgt
>
> https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
>
> https://etherpad.openstack.org/p/kolla-pike-ptg-images
>
> https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration
>
> If there is interest in continuing the discussions on a more regular basis,
> I'd like to propose we start a cross-project working group:
>
> https://wiki.openstack.org/wiki/Category:Working_Groups
>
> If I go ahead and do this is "deployment" a sufficiently project-neutral
> term to proceed with?
>
> I'd suggest we start with an informal WG, which it seems just requires an
> update to the wiki, e.g no need for any formal project team at this point?

I proposed the DWG:
https://review.openstack.org/#/c/442761

It's a rough draft for now, but any feedback is very welcome.

Thanks,

> Likewise I know some folks have expressed an interest in an IRC channel
> (openstack-deployment?), I'm happy to start with the ML but open to IRC
> also if someone is willing to set up the channel.
>
> Perhaps we can start by using the tag "deployment" in all cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?
>
> Please follow up here if anyone has other/better ideas on how to facilitate
> ongoing cross-team discussion and I'll do my best to help move things
> forward.
>
> Thanks!
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
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] [puppet][tripleo][release] puppet module versioning

[Alex Schultz]

Ahoy folks,

I would like to bring attention to deriving version numbers for puppet
modules (for packaging) as part of the release process.  Today we
uncovered an issue[0] in the way that version numbers were being
derived for packages which ultimately broke the TripleO CI upgrade
jobs because the master version was older than the last released Ocata
version.

As for a bit of history around the puppet version numbers, PEP-440 is
not supported in puppet and they are using a form of SemVer[1] .  So
we've historically chosen to just use X.Y.Z for our version numbers
and we usually end up bumping them prior to cutting a new release.
That being said, for the first time we've run into the issue where the
master branches metadata.json contained a version less than the
stable/ocata branch which resulted in the upgrade jobs failing.

In this case, we could have avoided the version issue by pushing a
version bump to master after cutting the stable/ocata branch to ensure
that master would be the next version.  We've talked about improving
the automation around the puppet versions in the past and I'm
wondering if this is something that would be best to be done in the
release process.  Now because puppet supports SemVer, we could
designate the next version as a X.Y.Z-dev version in the metadata.json
and would expect packagers to use the metadata.json file as the source
of truth for deriving version information and not using something like
pbr or git describe.  Right now as it sits for puppet modules, we
generally aren't touching the version information until we're ready to
release the next version which doesn't seem right for knowing what the
current version of the code actually is.

So what I'm proposing is to use a "-dev" pre-release identifier
between version releases for puppet modules.  As part of the tagging
process we could propose the next release version with "-dev" to the
repository.  The flow would look something like...

MASTER
1.0.0-dev
   +
   | TAG: M1
   +---> 1.0.0
   |
   v
MASTER
1.1.0-dev
   +
   | TAG: M2
   +---> 1.1.0
   |
   v
MASTER
1.2.0-dev
   +
   | TAG: M3
   +---> 1.2.0
   |
   v
MASTER
1.3.0-dev
   +
   | TAG: RC1
   +---> 1.3.0
   |
   v
RELEASE
   +
   | STABLE BRANCH
   +---> 1.4.0-dev
   |
   v
MASTER
2.0.0-dev

Currently since the metadata.json file is in the repository and for
the release process we're providing a git hash for the version to tag,
I'm not sure how the dropping of the "-dev" would work.  Since we
basically want the release process to take the hash, mangle the
metadata.json, commit it and use this new hash as the point to tag.
thoughts?

Thanks,
-Alex

[0] https://bugs.launchpad.net/tripleo/+bug/1669462
[1] https://github.com/puppetlabs/puppet/blob/master/lib/semver.rb#L10

__
OpenStack Development Mailing 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] [neutron] Should the ironic-neutron meeting start back up for pike?

[Michael Turek]

Hey all,

So at yesterday's ironic IRC meeting the question of whether or not the 
ironic neutron integration meeting should start back up. My 
understanding is that this meeting died down as it became more status 
oriented.


I'm wondering if it'd be worthwhile to kick it off again as 4 of pike's 
high priority items are neutron integration focused.


Personally it'd be a meeting I'd attend this cycle but I could 
understand if it's more trouble than it's worth.


Thoughts?

Thanks,
Mike


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

[openstack-dev] [nova] Question to clarify versioned notifications

[Matt Riedemann]

While digging through nova code today to compare versioned and 
unversioned notifications, and reading specs and seeing how seachlight 
handles nova notifications, I noticed that the unversioned notifications 
have a "compute." prefix in the name. The versioned notifications do not.


It also took me awhile but I also sorted out that unversioned 
notifications are on the 'notifications' topic which is the default in 
oslo.messaging ([oslo_messaging_notifications]topics) and versioned 
notifications are on the 'versioned_notifications' topic.


My question is, was it intentional to drop the "compute." prefix from 
the event type on the versioned notifications? I didn't see anything 
specifically stating that in the original spec [1].


Since the notifications are on independent topics it probably doesn't 
matter. I was just thinking about this from the searchlight perspective 
because they don't support nova versioned notifications yet and already 
have code to map the "compute." event types [2], I wasn't sure if they 
could re-use that and just listen on the 'versioned_notifications' 
topic. In talking with Steve McLellan it doesn't sound like the 
different event types format will be an issue.


[1] 
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/versioned-notification-api.html
[2] 
https://github.com/openstack/searchlight/blob/2.0.0/searchlight/elasticsearch/plugins/nova/notification_handler.py#L82


--

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] [TripleO][Heat] Selectively disabling deployment resources

[James Slagle]

I've been working on this spec for TripleO:
https://review.openstack.org/#/c/431745/

which allows users to selectively disable Heat deployment resources
for a given server (or server in the case of a *DeloymentGroup
resource).

Some of the main use cases in TripleO for such a feature are scaling
out compute nodes where you do not need to rerun Puppet (or make any
changes at all) on non-compute nodes, or to exclude nodes from hanging
a stack-update if you know they are unreachable or degraded for some
reason. There are others, but those are 2 of the major use cases.

I started by taking an approach that would be specific to TripleO.
Basically mapping all the deployment resources to a nested stack
containing the logic to selectively disable servers from the
deployment (using yaql) based on a provided parameter value. Here's
the main patch: https://review.openstack.org/#/c/442681/

After considering that complexity, particularly the yaql expression,
I'm wondering if it would be better to add this support natively to
Heat.

I was looking at the restricted_actions key in the resource_registry
and was thinking this might be a reasonable place to add such support.
It would require some changes to how restricted_actions work.

One change would be a method for specifying that restricted_actions
should not fail the stack operation if an action would have otherwise
been triggered. Currently the behavior is to raise an exception and
mark the stack failed if an action needs to be taken but has been
marked restricted. That would need to be tweaked to allow specifying
that that we don't want the stack to fail. One thought would be to
change the allowed values of restricted_actions to:

replace_fail
replace_ignore
update_fail
update_ignore
replace
update

where replace and update were synonyms for replace_fail/update_fail to
maintain backwards compatibility.

Another change would be to add logic to the Deployment resources
themselves to consider if any restricted_actions have been set on an
Server resources before triggering an updated deployment for a given
server.

It also might be nice to allow specifying restricted_actions on the
server's name property (which typically is the hostname) instead of
having to use the resource name. The reason being is that it is not
really feasibly to expect operators/users to have to represent the
full nested_stack structure in their resource_registry. They would
have to query and record nested_stack names just to refer to a given
server resource. Each ResourceGroup nested stack would be have to be
individually represented, etc. Unless there is another way I'm
overlooking.

Whether or not the restricted_actions approach is taken, is Heat
interested in this functionality natively? I think it would make for a
much cleaner implementation than something TripleO specific. I can
work on a Heat spec if there's interest, though I'd like to get some
early feedback.

Thanks.

-- 
-- 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] [Murano] ERROR murano.common.engine [-] yaql.language.exceptions.NoMatchingMethodException: No method "values" for receiver None matches supplied arguments

[Stan Lagun]

HOWEVER … for future reference …

how do I go about seeing the internal HEAT STACK that Murano builds based
on the Murano Application / Packaging ?




You can do it be ether

1) Obtaining from the Heat since the stack is accessible and there is an
API and UI to get the template

2) Grep murano-engine logs for "Pushing" followed by ay a stack template
JSON. Note, that Murano usually does series of stack updates rather than
creates it at once. Therefore there going to be several such log records
for each deployment


Regards,

Stan
__
OpenStack Development Mailing 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] [qa][keystone] Tempest will use Keystone v3 API as the default

[Monty Taylor]

On 03/07/2017 01:02 PM, Ken'ichi Ohmichi wrote:
> Hi,
> 
> This is a kind of notification as the mail title.
> 
> Now QA-team is trying to test most recent stable APIs which are marked
> as CURRENT in most components.
> The investigation is written on
> https://etherpad.openstack.org/p/tempest-api-versions-in-pike
> 
> On Keystone side, the V3 API is CURRENT and the V2 API is DEPRECATED.
> Until last week, the default config value of Tempest was the V2 for
> the authentication and the patch [1] has changed it to the V3.
> However Devstack still sets the V2 for Tempest config and we are using
> the V2 on the gate.
> The devstack patch [2] will change the config to the V3 for Tempest.
> I hope this change will be helpful for our future.

\o/


__
OpenStack Development Mailing 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] [Murano] Newton version of Murano fails trying to auto-import a Liberty version of io.murano.applications.zip

[Waines, Greg]

I am running a NEWTON version of Murano.

When I try to import a package that is using io.murano.applications classes 
(e.g. SingleServerApplication),
it seems to try to auto-import the liberty version of 
io.murano.applications.zip … and fails.

Is this a bug ?   Is it suppose to be using NEWTON version of 
io.murano.applciations.zip ?  Actually can’t find NEWTON version, is the URL 
wrong ?


[wrsroot@controller-0 newDemo(keystone_tenant1)]$ murano package-import 
com.wrs.titanium.murano.examples.afwDemo

Error Got non-ok status(404) while connecting to 
http://apps.openstack.org/api/v1/murano_repo/liberty/apps/io.murano.applications.zip
 occurred while parsing package io.murano.applications, required by 
com.wrs.titanium.murano.examples.afwDemo package

Inspecting required images

Importing package com.wrs.titanium.murano.examples.afwDemo

+--+-+--+-++---+-+-+

| ID   | Name| FQN  
| Author  | Active | Is Public 
| Type| Version |

+--+-+--+-++---+-+-+

| e7a08d26300e4812b9a5d0f91b2ad430 | APP FW Titanium Murano Demo App | 
com.wrs.titanium.murano.examples.afwDemo | Greg Waines, Wind River | True   |   
| Application | |

+--+-+--+-++---+-+-+

[wrsroot@controller-0 newDemo(keystone_tenant1)]$

let me know,
Greg.



__
OpenStack Development Mailing 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][keystone] Tempest will use Keystone v3 API as the default

[Ken'ichi Ohmichi]

Hi,

This is a kind of notification as the mail title.

Now QA-team is trying to test most recent stable APIs which are marked
as CURRENT in most components.
The investigation is written on
https://etherpad.openstack.org/p/tempest-api-versions-in-pike

On Keystone side, the V3 API is CURRENT and the V2 API is DEPRECATED.
Until last week, the default config value of Tempest was the V2 for
the authentication and the patch [1] has changed it to the V3.
However Devstack still sets the V2 for Tempest config and we are using
the V2 on the gate.
The devstack patch [2] will change the config to the V3 for Tempest.
I hope this change will be helpful for our future.

Thanks
Ken Ohmichi

---
[1]: https://review.openstack.org/#/c/441530/
[2]: https://review.openstack.org/#/c/441531/

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

Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from LBaaS v1 to v2

[Michael Johnson]

Saverio,

Unfortunately back when LBaaS v1 was deprecated (liberty) no automated
migration path was developed to move from LBaaS v1 to v2.  Some manual
database migration scripts were contributed, but you may still have
incompatible v1 load balancers that require manual intervention.  There is a
note about this in the networking guide:
https://docs.openstack.org/ocata/networking-guide/config-lbaas.html

I would recommend experimenting with the database-migration-from-v1-to-v2.py
script and working with your vendor (if you are using a vendor load
balancing engine) on a migration path.

Michael

-Original Message-
From: Saverio Proto [mailto:saverio.pr...@switch.ch] 
Sent: Tuesday, March 7, 2017 9:35 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from
LBaaS v1 to v2

Hello Michael,

thanks. Using your email I read this page:
https://docs.openstack.org/ocata/networking-guide/config-lbaas.html

It is still not clear to me if the command:

neutron-db-manage --subproject neutron-lbaas upgrade head

Will make the necessary database migrations from LBaaS v1 to v2 ?

Does this command triggers the execution of this code ?
https://github.com/openstack/neutron-lbaas/blob/master/tools/database-migrat
ion-from-v1-to-v2.py

On what openstack version should I run that neutron-db-manage command ?
I am currently in Mitaka.

Here I read:
https://docs.openstack.org/releasenotes/neutron-lbaas/newton.html
LBaaS API v1 has been removed. Do not upgrade before migrating to LBaaS API
v2.

This means I have to run 'neutron-db-manage --subproject neutron-lbaas
upgrade head' before upgrading ?

am I missing the page where the migration from V1 to V2 is explained ?

thank you

Saverio


On 07/03/17 17:33, Michael Johnson wrote:
> Hi Saverio,
> 
> I think the confusion is coming from neutron/neutron-lbaas/octavia.
> 
> Neutron-lbaas, prior to the Ocata series was a sub-project of neutron 
> and as such has it's own release notes:
> https://docs.openstack.org/releasenotes/neutron-lbaas/
> 
> As of Ocata, neutron-lbaas is part of the Octavia project
> (https://governance.openstack.org/tc/reference/projects/octavia.html) 
> and is no longer a sub-project of neutron.  In fact, we are actively 
> working to merge the neutron-lbaas v2 API into the Octavia API to 
> create a combined project.
> 
> Going forward you will probably want to monitor both neutron-lbaas and 
> the octavia release notes:
> https://docs.openstack.org/releasenotes/neutron-lbaas/
> https://docs.openstack.org/releasenotes/octavia/
> 
> To answer your original question, the LBaaS v1 API as removed in the 
> newton release of neutron-lbaas 
> (https://docs.openstack.org/releasenotes/neutron-lbaas/newton.html).
> 
> Michael
> 
> 
> -Original Message-
> From: Saverio Proto [mailto:saverio.pr...@switch.ch]
> Sent: Tuesday, March 7, 2017 1:09 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade 
> from LBaaS v1 to v2
> 
> Hello,
> 
> I am upgrading from Mitaka to Newton.
> 
> our Openstack cloud has in production LBaaSv1.
> 
> I read all the following release notes:
> 
> https://docs.openstack.org/releasenotes/neutron/liberty.html
> https://docs.openstack.org/releasenotes/neutron/mitaka.html
> https://docs.openstack.org/releasenotes/neutron/newton.html
> 
> In the liberty release notes I read:
> "The LBaaS V1 API is marked as deprecated and is planned to be removed 
> in a future release. Going forward, the LBaaS V2 API should be used."
> 
> But which one is the release that drops LBaaS V1 ?
> 
> I see this script is merged in stable/newton:
> 
> https://review.openstack.org/#/c/289595/
> 
> Can I still use LBaaS V1 in newton and do the migration before 
> upgrading to Ocata ?
> 
> The cherry-pick to Mitaka was abandoned:
> https://review.openstack.org/#/c/370103/
> 
> The Ocata release notes again dont say anything about LBaaS:
> https://docs.openstack.org/releasenotes/neutron/ocata.html
> 
> thank you
> 
> Saverio
> 
> 
> 
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 
> 15, direct +41 44 268 1573 saverio.pr...@switch.ch, 
> http://www.switch.ch
> 
> http://www.switch.ch/stories
> 
> __
>  OpenStack Development Mailing 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
> 

Re: [openstack-dev] [Murano] Errors on $.instance.deploy() ... WHEN RUNNING WITHOUT MURANO-AGENT RABBIT

[Waines, Greg]

Stan,
Success … this worked.
thank you very much for your help.

Greg.

( got another question but I’ll ask it in another thread )

From: Stan Lagun 
Date: Monday, March 6, 2017 at 6:10 PM
To: "openstack-dev@lists.openstack.org" , 
Greg Waines 
Cc: "Sun, Yicheng (Jerry)" 
Subject: Re: [openstack-dev] [Murano] Errors on $.instance.deploy() ... WHEN 
RUNNING WITHOUT MURANO-AGENT RABBIT

Hi Greg,

this is yet another similar bug in another place.
Here is the fix for you: https://review.openstack.org/#/c/442198/

Also please consider using LinuxInstance class instead of LinuxMuranoInstance.
LinuxInstance doesn't try to build agent config and push it through cloud-init 
and thus should not
have such problems

Regards,
Stan



On March 6, 2017 at 6:51:11 AM, Waines, Greg 
(greg.wai...@windriver.com) wrote:
Hey Stan,

We tried doing the changes from https://review.openstack.org/#/c/441477/
i.e.
changing the first couple of lines in the __init__ of AgentListener in 
agent_listener.py
 class AgentListener(object):
 def __init__(self, name):
-self._enabled = False
-if CONF.engine.disable_murano_agent:
-return
-self._enabled = True
+self._enabled = not CONF.engine.disable_murano_agent
 self._results_queue = str('-execution-results-%s' % name.lower())
 self._subscriptions = {}
 self._receive_thread = None


But still get the following issue: ??? Any suggestions ???
Greg.



2017-03-06 14:24:01.870 28884 ERROR murano.common.engine [-]
  AttributeError: 'Agent' object has no attribute '_queue'
  Traceback (most recent call last):
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/Environment.yaml",
 line 120:9 in method deploy of type io.murano.Environment
$.applications.pselect($.deploy())
File 
"/tmp/murano-packages-cache/wrs.titanium.murano.examples.VmFip_NoAppDeploy/0.0.0/829a861c408a4516b0589d04cce23248/Classes/VmFip_NoAppDeploy.yaml",
 line 41:13 in method deploy of type 
wrs.titanium.murano.examples.VmFip_NoAppDeploy
$.instance.deploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/Instance.yaml",
 line 193:9 in method deploy of type io.murano.resources.Instance
$this.beginDeploy()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/Instance.yaml",
 line 131:28 in method beginDeploy of type io.murano.resources.Instance
$.prepareUserData()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/LinuxMuranoInstance.yaml",
 line 14:19 in method prepareUserData of type 
io.murano.resources.LinuxMuranoInstance
$.generateUserData()
File 
"/tmp/murano-packages-cache/io.murano/0.0.0/3317e706ecd1417bb748361a6a3385d2/Classes/resources/LinuxMuranoInstance.yaml",
 line 80:39 in method generateUserData of type 
io.murano.resources.LinuxMuranoInstance
$.agent.queueName()
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 58 in 
method evaluate
for d_key, d_value in six.iteritems(value))
File "/usr/lib/python2.7/site-packages/yaql/language/utils.py", line 122 in 
method __init__
self._d = dict(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 58 in 
method 
for d_key, d_value in six.iteritems(value))
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 53 in 
method evaluate
return value(context)
File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", line 
85 in method __call__
return self._parsed_expression.evaluate(context=context)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
165 in method evaluate
return self(utils.NO_VALUE, context, self.engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
156 in method __call__
return super(Statement, self).__call__(receiver, context, engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, 
context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in 
method call
name, all_overloads, engine, receiver, data_context, args, kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 

Re: [openstack-dev] [Sahara] Cross Project Liaisons

[Telles Nobrega]

Great Vitaly. I will update that.

On Tue, Mar 7, 2017 at 12:02 PM Vitaly Gridnev 
wrote:

> I can continue to work with Stable branches and with infra, I think.
>
> Best regards,
> Vitaly Gridnev
>
>
> On Mar 7, 2017, at 12:31 AM, Telles Nobrega  wrote:
>
> Hello Saharans, in the last two or three cycles our team has undergone
>  some changes and we need to update our Cross project liaisons.
> Currently we have the following setup:
>
> *| Project  |Liaison |*
> | Oslo  | Huichun Lu, Elise Gafford |
> | Release Management | Telles Nobrega |
> | QA| Luigi Toscano  |
> | Documentation   |   |
> | Stable Branch| Vitaly Gridnev  |
> | Vulnerability Mg.| Michael McCune, Vitaly|
> | Logging working group| Elise Gafford|
> | Infra  | Nikita, Vitaly|
> | Product Working Gr   | Elise Gafford|
> | I18n  | Nikita Konovalov   |
> *| Cross project spec | Michael McCune, Vitaly|*
>
> So, basically we need to update the liaisons for most of the projects,
> Nikita and Elise are both working limited on the project and may speak up
> if they still want to be liaisons on the projects they are signed up we
> will be glad, if not we need to assign new people to them.
>
> Michael is no longer working actively on Sahara so we need to replace him.
> Vitaly please let us know what projects do you want to continue working as
> liaisons.
> I will work as liaison for documentation with Elise (previously agreed on
> Sahara meeting) and also arrange the other projects depending on people's
> will and availability.
>
> Thanks all,
>
> __
> OpenStack Development Mailing 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] [cross-project][nova][cinder][designate][neutron] Common support-matrix.py

[Doug Hellmann]

On Mon, Mar 6, 2017, at 08:42 PM, Sean Dague wrote:
> On 03/06/2017 06:27 PM, Mike Perez wrote:
> > On 15:55 Mar 02, Morales, Victor wrote:
> >> I got this link[11] from Ankur, apparently Nova and Neutron has already 
> >> started a common effort
> >>
> >> [11] https://review.openstack.org/#/c/330027/
> >
> > Thanks for pointing me to this Victor! I have spoke to Doug and Sean Dague 
> > in
> > #openstack-dev about this, and I think it'll be fine for us to keep the 
> > current
> > INI file approach. I've reached out to Ankur to hopefully restore and 
> > continue
> > this effort.
> >
> > What do Designate and Cinder folks think of this approach?
> 
> The only thing I'd suggest is not to wrap it into oslosphinx but just do 
> it as a dedicated extension. When we did os-api-ref we eventually had to 
> jump themes because this was going to end up outside the devref in 
> projects, and being decoupled made that possible.

+1 -- we have lots of experience releasing libraries, and the "theme"
component in oslosphinx is likely to go away as soon as the docs team
publishes a compatible version of their theme library.

Doug

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

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

Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from LBaaS v1 to v2

[Saverio Proto]

Hello Michael,

thanks. Using your email I read this page:
https://docs.openstack.org/ocata/networking-guide/config-lbaas.html

It is still not clear to me if the command:

neutron-db-manage --subproject neutron-lbaas upgrade head

Will make the necessary database migrations from LBaaS v1 to v2 ?

Does this command triggers the execution of this code ?
https://github.com/openstack/neutron-lbaas/blob/master/tools/database-migration-from-v1-to-v2.py

On what openstack version should I run that neutron-db-manage command ?
I am currently in Mitaka.

Here I read:
https://docs.openstack.org/releasenotes/neutron-lbaas/newton.html
LBaaS API v1 has been removed. Do not upgrade before migrating to LBaaS
API v2.

This means I have to run 'neutron-db-manage --subproject neutron-lbaas
upgrade head' before upgrading ?

am I missing the page where the migration from V1 to V2 is explained ?

thank you

Saverio


On 07/03/17 17:33, Michael Johnson wrote:
> Hi Saverio,
> 
> I think the confusion is coming from neutron/neutron-lbaas/octavia.
> 
> Neutron-lbaas, prior to the Ocata series was a sub-project of neutron and as
> such has it's own release notes:
> https://docs.openstack.org/releasenotes/neutron-lbaas/
> 
> As of Ocata, neutron-lbaas is part of the Octavia project
> (https://governance.openstack.org/tc/reference/projects/octavia.html) and is
> no longer a sub-project of neutron.  In fact, we are actively working to
> merge the neutron-lbaas v2 API into the Octavia API to create a combined
> project.
> 
> Going forward you will probably want to monitor both neutron-lbaas and the
> octavia release notes:
> https://docs.openstack.org/releasenotes/neutron-lbaas/
> https://docs.openstack.org/releasenotes/octavia/
> 
> To answer your original question, the LBaaS v1 API as removed in the newton
> release of neutron-lbaas
> (https://docs.openstack.org/releasenotes/neutron-lbaas/newton.html).
> 
> Michael
> 
> 
> -Original Message-
> From: Saverio Proto [mailto:saverio.pr...@switch.ch] 
> Sent: Tuesday, March 7, 2017 1:09 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from
> LBaaS v1 to v2
> 
> Hello,
> 
> I am upgrading from Mitaka to Newton.
> 
> our Openstack cloud has in production LBaaSv1.
> 
> I read all the following release notes:
> 
> https://docs.openstack.org/releasenotes/neutron/liberty.html
> https://docs.openstack.org/releasenotes/neutron/mitaka.html
> https://docs.openstack.org/releasenotes/neutron/newton.html
> 
> In the liberty release notes I read:
> "The LBaaS V1 API is marked as deprecated and is planned to be removed in a
> future release. Going forward, the LBaaS V2 API should be used."
> 
> But which one is the release that drops LBaaS V1 ?
> 
> I see this script is merged in stable/newton:
> 
> https://review.openstack.org/#/c/289595/
> 
> Can I still use LBaaS V1 in newton and do the migration before upgrading to
> Ocata ?
> 
> The cherry-pick to Mitaka was abandoned:
> https://review.openstack.org/#/c/370103/
> 
> The Ocata release notes again dont say anything about LBaaS:
> https://docs.openstack.org/releasenotes/neutron/ocata.html
> 
> thank you
> 
> Saverio
> 
> 
> 
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15,
> direct +41 44 268 1573 saverio.pr...@switch.ch, http://www.switch.ch
> 
> http://www.switch.ch/stories
> 
> __
> OpenStack Development Mailing 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
> 


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

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

Re: [openstack-dev] [all] Small steps for Go

[Clint Byrum]

Excerpts from Hayes, Graham's message of 2017-03-07 14:19:02 +:
> On 07/03/2017 13:22, Davanum Srinivas wrote:
> > Folks,
> >
> > Anyone interested? https://etherpad.openstack.org/p/go-and-containers
> >
> > Thanks,
> > Dims
> >
> 
> The first thing that is required (according to the new guidelines) is
> for there to be a technical reason we need to use go, and cannot use
> python. [0]
> 
> This was the major point thrown at designate when we asked for
> permission - if there is now a golang project for the sake of
> a golang project, that would seem at odds with these (brand new)
> requirements.
> 
> The only item in the linked etherpad that would fit that requirement
> is the Go Common Lib, which is a requirement for any project who wants
> to use go.
> 
> Do we want to allow projects innovate, or do we just want Golang in
> OpenStack now? I honestly cannot follow what is going on in this area.
> 

There's a nasty assumption wrapped in that sentence that isn't quite
fair. We've always wanted projects to innovate, but the choice of common
language was entirely designed to put people in a box that was easier
for operators to consume and debug.

I don't see an actual real problem statement that takes operators and
users into account in that etherpad*. IMO language bindings is a red
herring, we have REST API's and they're not so bad that they have to
be wrapped in convenience libs *cough*OaktreeShade*cough*.

I'd really like to see *users* and/or *operators* be the focus of any
efforts around Golang, or Lisp, or anything else we ship.

Designate felt that the operators were better served by a Golang
transfer daemon (IIRC). Hummingbird was created by Swift operators to
deal with their IO concurrency problems. I _like_ those efforts (now
that I understand them, which was not easy). But the etherpad kind of
reads to me like "let's make Go things because container things".. maybe
somebody can explain it to me like I'm 5?


* Kolla is a deployment project, and imo, can do Golang the same way
  openstack-ansible does ansible and puppet does puppet.

__
OpenStack Development Mailing 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] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Duarte Cardoso, Igor]

Hi Vikash,
Please stick to pastebin for complete logs.

Check your migration files:

FAILED: Contract HEAD file does not match migration timeline head, expected: 
48072cb59133

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Tuesday, March 7, 2017 5:03 PM
To: openstack-dev 
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Complete log:

 py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
py35 installdeps: 
-r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt, 
-r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
py35 installed: 
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated,  f = open(fullname, 
"rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
 
git+https://github.com/openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e
 
git+https://github.com/openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,python-designateclient==2.6.0,python-editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclient==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,stevedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==3.7.1,testrepository==0.0.20,testresources==2.0.1,testscenarios==0.5.0,testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.0,unittest2==1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.6.3,WebTest==2.0.26,wrapt==1.10.8
py35 runtests: PYTHONHASHSEED='177840'
py35 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
py35 runtests: commands[1] | find . -type d -name __pycache__ -delete
py35 runtests: commands[2] | 
/home/vikash/guess_vk/python-dev/networking-sfc/tools/ostestr_compat_shim.sh
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/positional/__init__.py:74:
 DeprecationWarning: inspect.getargspec() is deprecated, use 
inspect.signature() instead
  spec = inspect.getargspec(func)
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/wrapt/wrappers.py:522:
 DeprecationWarning: Using the 

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Complete log:

 py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
py35 installdeps:
-r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt,
-r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
py35 installed:
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
"rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
git+
https://github.com/openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e
git+
https://github.com/openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,python-designateclient==2.6.0,python-editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclient==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,stevedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==3.7.1,testrepository==0.0.20,testresources==2.0.1,testscenarios==0.5.0,testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.0,unittest2==1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.6.3,WebTest==2.0.26,wrapt==1.10.8
py35 runtests: PYTHONHASHSEED='177840'
py35 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
py35 runtests: commands[1] | find . -type d -name __pycache__ -delete
py35 runtests: commands[2] |
/home/vikash/guess_vk/python-dev/networking-sfc/tools/ostestr_compat_shim.sh

/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/positional/__init__.py:74:
DeprecationWarning: inspect.getargspec() is deprecated, use
inspect.signature() instead
  spec = inspect.getargspec(func)
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/wrapt/wrappers.py:522:
DeprecationWarning: Using the 'sqlite_db' argument is deprecated: Config
option sqlite_db is deprecated for removal,please use option `connection`.
  args, kwargs)
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/wrapt/wrappers.py:561:
DeprecationWarning: Using the 'retry_on_request' argument is deprecated:
Retry on request is always enabled
  args, kwargs)

Re: [openstack-dev] [oslo] question about oslo_utils and oslo_versonedobjects

[Jay Pipes]

On 03/07/2017 01:34 AM, zengchen wrote:

Hi, guys:
 I find a non-coincidence definition in Oslo,

 oslo_utils.timeutils.utcnow is defined like this:
 def utcnow(with_timezone=False):

oslo_versonedobjects.fields.DateTimeField is defined like this
classDateTimeField(AutoTypedField): def__init__(self, tzinfo_aware=True,
**kwargs):

a = utcnow()
class ABC(VersionedObject):
fields = {
created_at = fields.DateTimeField()
}
b = ABC(), and fill it by db record.

If I compare a and b.created_at,  it will raise an exception like this:
   'TypeError: can't compare offset-naive and offset-aware datetimes'
because a's value is like this:
datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
b.created_at 's value is like this:
 datetime.datetime(2017, 3, 7, 2, 35, 27,
400786,*tzinfo=*)

   Can these two kinds of time's definition be coincident? For example:
   def utcnow(with_timezone=*False*):

   class DateTimeField(AutoTypedField):
def __init__(self, tzinfo_aware=*False*, **kwargs):


Hi Zeng,

Yes, you will want to use utcnow(with_timezone=True) and the default 
ovo.fields.DateTimeField definition *or* use utcnow() and a 
ovo.fields.DateTimeField(tzinfo_aware=False) definition.


Best,
-jay

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

Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from LBaaS v1 to v2

[Michael Johnson]

Hi Saverio,

I think the confusion is coming from neutron/neutron-lbaas/octavia.

Neutron-lbaas, prior to the Ocata series was a sub-project of neutron and as
such has it's own release notes:
https://docs.openstack.org/releasenotes/neutron-lbaas/

As of Ocata, neutron-lbaas is part of the Octavia project
(https://governance.openstack.org/tc/reference/projects/octavia.html) and is
no longer a sub-project of neutron.  In fact, we are actively working to
merge the neutron-lbaas v2 API into the Octavia API to create a combined
project.

Going forward you will probably want to monitor both neutron-lbaas and the
octavia release notes:
https://docs.openstack.org/releasenotes/neutron-lbaas/
https://docs.openstack.org/releasenotes/octavia/

To answer your original question, the LBaaS v1 API as removed in the newton
release of neutron-lbaas
(https://docs.openstack.org/releasenotes/neutron-lbaas/newton.html).

Michael


-Original Message-
From: Saverio Proto [mailto:saverio.pr...@switch.ch] 
Sent: Tuesday, March 7, 2017 1:09 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from
LBaaS v1 to v2

Hello,

I am upgrading from Mitaka to Newton.

our Openstack cloud has in production LBaaSv1.

I read all the following release notes:

https://docs.openstack.org/releasenotes/neutron/liberty.html
https://docs.openstack.org/releasenotes/neutron/mitaka.html
https://docs.openstack.org/releasenotes/neutron/newton.html

In the liberty release notes I read:
"The LBaaS V1 API is marked as deprecated and is planned to be removed in a
future release. Going forward, the LBaaS V2 API should be used."

But which one is the release that drops LBaaS V1 ?

I see this script is merged in stable/newton:

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

Can I still use LBaaS V1 in newton and do the migration before upgrading to
Ocata ?

The cherry-pick to Mitaka was abandoned:
https://review.openstack.org/#/c/370103/

The Ocata release notes again dont say anything about LBaaS:
https://docs.openstack.org/releasenotes/neutron/ocata.html

thank you

Saverio



--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15,
direct +41 44 268 1573 saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing 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] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Hi,

I was testing patch on master branch, but the test is failing because
of the import error.

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

-- 
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] [ironic] OpenStack client default ironic API version

[Loo, Ruby]

On 2017-03-06, 3:46 PM, "Mario Villaplana"  wrote:

Hi ironic,

At the PTG, an issue regarding the default version of the ironic API
used in our python-openstackclient plugin was discussed. [0] In short,
the issue is that we default to a very old API version when the user
doesn't otherwise specify it. This limits discoverability of new
features and makes the client more difficult to use for deployments
running the latest version of the code.

We came to the following consensus:

1. For a deprecation period, we should log a warning whenever the user
doesn't specify an API version, informing them of this change.

2. After the deprecation period:

a) OSC baremetal plugin will default to the latest available version

I think OSC and ironic CLI have the same behaviour -- are we only interested in 
OSC or are we interested in both, except that we also want to at some point 
soon perhaps, deprecate ironic CLI?

Also, by 'latest available version', the OSC plugin knows (or thinks it knows) 
what the latest version is [1]. Will you be using that, or 'latest'?

b) Specifying just macroversion will default to latest microversion
within that macroversion (example: --os-baremetal-api-version=1 would
default to 1.31 if 1.31 is the last microversion with 1 macroversion,
even if we have API 2.2 supported)

I have a patch up for review with the deprecation warning:
https://review.openstack.org/442153

Do you have an RFE? I'd like a spec for this too please.

Please comment on that patch with any concerns.

We also still have yet to decide what a suitable deprecation period is
for this change, as far as I'm aware. Please respond to this email
with any suggestions on the deprecation period.

Thanks,
Mario


[0] https://etherpad.openstack.org/p/ironic-pike-ptg-operations L30

Thank YOU!

--ruby

[1] 
https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L29

__
OpenStack Development Mailing 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] OpenStack client default ironic API version

[Miles Gould]

On 07/03/17 12:14, Jim Rollenhagen wrote:

I'm also good with the standard deprecation period for this.


+1 to "standard deprecation period" - sorry, I'd misremembered what that 
was.


Miles

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

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Matt Riedemann]

On 3/7/2017 6:35 AM, Thierry Carrez wrote:

Hi everyone,

I recently got more information about the space dedicated to the "Forum"
at the OpenStack Summit in Boston. We'll have three different types of
spaces available.

1/ "Forum" proper

There will be 3 medium-sized fishbowl rooms for cross-community
discussions. Topics for the discussions in that space will be selected
and scheduled by a committee formed of TC and UC members, facilitated by
Foundation staff members. In case you missed it, the brainstorming for
topics started last week, announced by Emilien in that email:

http://lists.openstack.org/pipermail/openstack-dev/2017-March/113115.html

2/ "On-boarding" rooms

We'll have two rooms set up in classroom style, dedicated to project
teams and workgroups who want to on-board new team members. Those can
for example be booked by project teams to run an introduction to their
codebase to prospective new contributors, in the hope that they will
join their team in the future. Those are not meant to do traditional
user-facing "project intro" talks -- there is space in the conference
for that. They are meant to provide the next logical step in
contributing after Upstream University and being involved on the
sidelines. It covers the missing link for prospective contributors
between attending Summit and coming to the PTG. Kendall Nelson and Mike
Perez will soon announce the details for this, including how projects
can sign up.

3/ Free hacking/meetup space

We'll have four or five rooms populated with roundtables for ad-hoc
discussions and hacking. We don't have specific plans for these -- we
could set up something like the PTG ethercalc for teams to book the
space, or keep it open. Maybe half/half.

More details on all this as they come up.
Hoping to see you there !



Thanks for the details, this helps.

Any idea what the breakdown in days are going to be, like "Forum" 
sessions are Monday/Tuesday or Tuesday/Wednesday, or are they all four days?


The nova people that are going to be there would like to take advantage 
of the face-to-face time to work on some of the priority items for the 
Pike release in the free hacking/meetup space but without knowing when 
the other sessions are going to be it's hard to know when we can 
schedule space in the hacking pit.


If that's all TBD that's fair, I just wanted to ask.

--

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] [puppet] puppet-cep beaker test

[Alex Schultz]

Hey Stefan,

On Tue, Mar 7, 2017 at 7:09 AM, Scheglmann, Stefan  wrote:
> Hi,
>
> currently got some problems running the beaker test for the puppet-cep 
> module. Working on OSX using Vagrant version 1.8.6 and VirtualBox version  
> 5.1.14. Call is 'BEAKER_destroy=no BEAKER_debug=1 bundle exec --verbose rspec 
> spec/acceptance’ output in  http://pastebin.com/w5ifgrvd
>

Try running:
PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1 bundle exec
--verbose rspec spec/acceptance

Thanks,
-Alex

> Trace:
> An error occurred in a `before(:suite)` hook.
> Failure/Error: raise CommandFailure, "Host '#{self}' exited with 
> #{result.exit_code} running:\n #{cmdline}\nLast #{@options[:trace_limit]} 
> lines of output were:\n#{result.formatted_output(@options[:trace_limit])}"
> Beaker::Host::CommandFailure:
>  Host 'first' exited with 127 running:
>   ZUUL_REF= ZUUL_BRANCH= ZUUL_URL= PUPPET_MAJ_VERSION= bash 
> openstack/puppet-openstack-integration/install_modules.sh
>  Last 10 lines of output were:
> + '[' -n 'SHELLOPTS=braceexpand:hashall:interactive-comments:xtrace
> if [ -n "$(set | grep xtrace)" ]; then
> local enable_xtrace='\''yes'\'';
> if [ -n "${enable_xtrace}" ]; then' ']'
> + set +x
> 
> 
> | Install r10k
>  |
> 
> 
> + gem install fast_gettext -v '< 1.2.0'
> openstack/puppet-openstack-integration/install_modules.sh: line 29: 
> gem: command not found
>
> It seems like that the box beaker is using (puppetlabs/ubuntu-14.04-64-nocm), 
> somehow ends up with has puppet 4.x installed. I could not exactly pin down 
> how this happens, cause when i sin up some VM just from that base box and 
> install puppet, i end up with 3.4. But during the beaker tests it ends up 
> with puppet 4 and in puppet 4 some paths have changed. /opt/puppetlabs/bin is 
> just for the 'public' applications and the ‘private' ones like gem or ruby 
> are in /opt/puppetlabs/puppet/bin. Therefore the 
> openstack/puppet-openstack-integration/install_modules.sh script fails on 
> installation of r10k, cause it cannot find gem and later on it fails on the 
> r10k call cause it is also installed to /opt/puppetlabs/puppet/bin.
> Symlinking gem and r10k in an provisioned machine, and rerun the tests fixes 
> the problem. Currently i am doing all this cause i added some functionalities 
> for the puppet-cep manifests to support bluestone/rocksdb and some additional 
> config params which i would like to see in upstream.
>
>
> Greets Stefan
> __
> OpenStack Development Mailing 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] [infra][tripleo] initial discussion for a new periodic pipeline

[Wesley Hayutin]

Greetings,

The TripleO team would like to initiate a conversation about the
possibility of creating a new pipeline in Openstack Infra to allow a set of
jobs to run periodically every four hours [2].
The background and context of why such a pipeline is required is as
follows.  TripleO CI executes installs of Openstack with rpm packages from
a tool called delorean [1].  Every commit from upstream is built into a
rpm several times each hour of the day.  These freshly built packages need
to be validated before they are allowed to be used in the TripleO check
gates to ensure we have stable and consistent CI results.  Currently the
validation of the new rpms is done every 24 hours via a periodic pipeline.
In practice this periodic validation finds a working set of rpms roughly
once maybe twice a week depending on the time in the release, they happen
much more often at the beginning and end of each cycle.

There is often a window of time where an upstream fix has been merged and
the set of rpms will pass this validation and when a new issue/bug is
introduced into the latest set of rpms.  Validating the set of rpms only
every 24 hours does not intersect with that "working window" often enough.
It's good practice to always be testing with the latest merged code in CI
and that is what we hope to improve on in TripleO by increasing the cadence
of this validation.   A suggestion was made at the last PTG in Atlanta to
create a new pipeline to accommodate an increased cadence hopefully to
every four hours.

I suspect there will be roughly 4-6 jobs kicked off in this pipeline.  The
exact jobs that will be used is not final but will probably include [3]

I am hoping to kick off the conversation regarding how to properly proceed
with this task here, and to generally notify the community of our
intentions.

Thank you for reading through this and considering the requirement.
Wes


[1]
https://blogs.rdoproject.org/7834/delorean-openstack-packages-from-the-future
[2]
https://blueprints.launchpad.net/tripleo/+spec/increase-cadence-of-tripleo-promotions
[3]
gate-tripleo-ci-centos-7-scenario001-multinode
gate-tripleo-ci-centos-7-scenario002-multinode
gate-tripleo-ci-centos-7-scenario003-multinode
gate-tripleo-ci-centos-7-scenario004-multinode
gate-tripleo-ci-centos-7-multinode-upgrades-nv
gate-tripleo-ci-centos-7-ovb-ha-ipv6
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] image import sync tomorrow

[Brian Rosmaita]

Sorry for the late notice, but we'll be having a one-hour image import
sync via video conference at 16:00 UTC tomorrow (8 March 2017).

Watch the ML for more details later today, plus connection info will be
posted in #openstack-glance around 15:45 UTC tomorrow.

cheers,
brian

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

Re: [openstack-dev] [cross-project][nova][cinder][designate][neutron] Common support-matrix.py

[Hayes, Graham]

On 01/03/2017 23:53, Mike Perez wrote:
> Hey all,
>
> I kicked off a thread [1] to start talking about approaches with improving
> vendor discoveribility by improving our Market Place [2]. In order to improve
> our market place, having the projects be more part of the process would allow
> the information to be more accurate of what vendors have good support in the
> respected service.
>
> It was discovered that we have a common solution of using INI files and 
> parsing
> that with a common support-matrix.py script that originated out of nova [3].
> I would like to propose we push this into some common sphinx extension 
> project.
> Are there any suggestions of where that could live?
>
> I've look at how Nova [3][4], Neutron [5][6] and Designate [7][8] are doing
> this today. Nova and Neutron are pretty close, and Designate is a much more
> simplified version. Cinder [9][10] is not using INI files, but instead going
> off the driver classes themselves. Are there any other projects I'm missing?
>
> Cinder and Designate have drivers per row, as oppose to Nova and Neutron
> which have features per row. This makes sense given the difference in drivers
> versus features?
>
> I'm assuming the Designate matrix is saying every driver supports every 
> feature
> in its API? If so, that's so awesome and makes me happy.

yes :) - our drivers are *very* thin and just do zone create / update /
delete, and the rest of the complexity is in Designate.

> I would like to start brainstorming on how we can converge on a common matrix
> table design so things are a bit more consistent and easier for a common
> parsing tool.
>

I think having an os-api-ref for drivers (os-driver-ref ??) is a great
idea. What I would like to see from that is a common data format for
listing drivers, which we could then use for a overall driver "market
place".

What we (designate) store per driver:

Name
Type (Agent vs Zone Transfer)
Status (Which is a dynamic list in the ini file)
Maintainers
Variations (e.g. PowerDNS with MySQL vs pgSQL)
Repo

I want to extend ours to include:

Links to setup / usage docs for that driver.
Links to example pool config snippets.

I understand that ^ may be quite difficult to get right in a generic
way, so if we cannot make it work, we can keep ours separate.

Thanks,

Graham

>
> [1] - 
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html
> [2] - https://www.openstack.org/marketplace/drivers/
> [3] - 
> https://docs.openstack.org/developer/nova/support-matrix.html#operation_maintenance_mode
> [4] - 
> http://git.openstack.org/cgit/openstack/nova/tree/doc/ext/support_matrix.py
> [5] - https://review.openstack.org/#/c/318192/76
> [6] - 
> http://docs-draft.openstack.org/92/318192/76/check/gate-neutron-docs-ubuntu-xenial/48cdeb7//doc/build/html/feature_classification/general_feature_support_matrix.html
> [7] - 
> https://git.openstack.org/cgit/openstack/designate/tree/doc/ext/support_matrix.py
> [8] - https://docs.openstack.org/developer/designate/support-matrix.html
> [9] - https://review.openstack.org/#/c/371169/15
> [10] - 
> http://docs-draft.openstack.org/69/371169/15/check/gate-cinder-docs-ubuntu-xenial/aa1bdb1//doc/build/html/driver_support_matrix.html
>


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

Re: [openstack-dev] [cinder] Create backup with snapshots

[yang, xing]

Excellent!  Review comments added to your patch.

Thanks!

Xing


From: 王玺源 [wangxiyuan1...@gmail.com]
Sent: Monday, March 6, 2017 8:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Create backup with snapshots

Cool. That's the way which I desire  mostly. Here is the bug: 
https://bugs.launchpad.net/cinder/+bug/1670541 and I'll update the patch ASAP.

Thanks very much for your explanation and  suggestion.

2017-03-06 22:43 GMT+08:00 yang, xing 
>:
I don't think we should add a separate API for backing up a snapshot.  We could 
do a check in the backup API to see whether snapshot_id is provided or not.  If 
provided, we change the status of the snapshot; otherwise, we change the status 
of the volume as usual.  Changes are needed in backup/api.py and 
backup/manager.py (to change the status back).

Do you want to submit a bug fix for this change?

Thanks,
Xing



From: 王玺源 [wangxiyuan1...@gmail.com]
Sent: Sunday, March 5, 2017 9:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Create backup with snapshots

Thanks, Xing.

I got the history reason now. So is it possible that we can devide the create 
API into two APIs? One is for create backup from volumes, another is from 
snapshots. Then we can control the volumes' and snapshots' status dividually 
and easily.

When create a backup from a large snapshot, such as larger than 1 TB, It will 
costs few hours generally. It's really a problem that the volume is not 
available for such a long time.

2017-03-03 22:43 GMT+08:00 yang, xing 
>>:
In the original backup API design, volume_id is a required field.  In the CLI, 
volume_id is positional and required as well.  So when I added support to 
backup from a snapshot, I added snapshot_id as an optional field in the request 
body of the backup API.  While backup is in process, you cannot delete the 
volume.  Backup from snapshot and backup from volume are using the same API.  
So I think volume status should be changed to “backing-up” to be consistent.  
Now I’m thinking the status of the snapshot should be changed to “backing-up” 
too if snapshot_id is provided.

Thanks,
Xing



From: 王玺源 
[wangxiyuan1...@gmail.com>]
Sent: Thursday, March 2, 2017 10:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder] Create backup with snapshots

Hi cinder team:
We met a problem about backup create recently.

The backup can be created from volumes or snapshots. In the both cases, the 
volume' s status is set to 'backing-up'.

But as I know, when users create backup with snapshots, the volume is not 
used(Correct me if I'm wrong). So why the volume's status is changed ? Should 
it keep available? It's a little strange that the volume is "backing-up" but 
actually only the snapshot is used for backup creation. the volume in 
"backing-up" means that it can't be used for some other actions. Such as: 
attach, delete, export to image, extend, create from volume, create backup from 
volume and so on.

So is there any reason we changed the volume' status here? Or is there any 
third part driver need the volume's status must be "backing-up" when create 
backup from snapshots?

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

Re: [openstack-dev] [all] Small steps for Go

[Hayes, Graham]

On 07/03/2017 13:22, Davanum Srinivas wrote:
> Folks,
>
> Anyone interested? https://etherpad.openstack.org/p/go-and-containers
>
> Thanks,
> Dims
>

The first thing that is required (according to the new guidelines) is
for there to be a technical reason we need to use go, and cannot use
python. [0]

This was the major point thrown at designate when we asked for
permission - if there is now a golang project for the sake of
a golang project, that would seem at odds with these (brand new)
requirements.

The only item in the linked etherpad that would fit that requirement
is the Go Common Lib, which is a requirement for any project who wants
to use go.

Do we want to allow projects innovate, or do we just want Golang in
OpenStack now? I honestly cannot follow what is going on in this area.

0 - 
https://governance.openstack.org/tc/reference/new-language-requirements.html#step-1-use-case-analysis



__
OpenStack Development Mailing 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] [Sahara] Cross Project Liaisons

[Vitaly Gridnev]

I can continue to work with Stable branches and with infra, I think. 

Best regards,
Vitaly Gridnev


> On Mar 7, 2017, at 12:31 AM, Telles Nobrega  wrote:
> 
> Hello Saharans, in the last two or three cycles our team has undergone  some 
> changes and we need to update our Cross project liaisons. 
> Currently we have the following setup:
> 
> | Project  |Liaison |
> | Oslo  | Huichun Lu, Elise Gafford |
> | Release Management | Telles Nobrega |
> | QA| Luigi Toscano  |
> | Documentation   |   |
> | Stable Branch| Vitaly Gridnev  |
> | Vulnerability Mg.| Michael McCune, Vitaly|
> | Logging working group| Elise Gafford|
> | Infra  | Nikita, Vitaly|
> | Product Working Gr   | Elise Gafford|
> | I18n  | Nikita Konovalov   |
> | Cross project spec | Michael McCune, Vitaly|
> 
> So, basically we need to update the liaisons for most of the projects, Nikita 
> and Elise are both working limited on the project and may speak up if they 
> still want to be liaisons on the projects they are signed up we will be glad, 
> if not we need to assign new people to them.
> 
> Michael is no longer working actively on Sahara so we need to replace him. 
> Vitaly please let us know what projects do you want to continue working as 
> liaisons.
> I will work as liaison for documentation with Elise (previously agreed on 
> Sahara meeting) and also arrange the other projects depending on people's 
> will and availability.
> 
> Thanks all,
> 
> __
> OpenStack Development Mailing 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] [puppet] puppet-cep beaker test

[Scheglmann, Stefan]

Hi,

currently got some problems running the beaker test for the puppet-cep module. 
Working on OSX using Vagrant version 1.8.6 and VirtualBox version  5.1.14. Call 
is 'BEAKER_destroy=no BEAKER_debug=1 bundle exec --verbose rspec 
spec/acceptance’ output in  http://pastebin.com/w5ifgrvd

Trace:
An error occurred in a `before(:suite)` hook.
Failure/Error: raise CommandFailure, "Host '#{self}' exited with 
#{result.exit_code} running:\n #{cmdline}\nLast #{@options[:trace_limit]} lines 
of output were:\n#{result.formatted_output(@options[:trace_limit])}"
Beaker::Host::CommandFailure:
 Host 'first' exited with 127 running:
  ZUUL_REF= ZUUL_BRANCH= ZUUL_URL= PUPPET_MAJ_VERSION= bash 
openstack/puppet-openstack-integration/install_modules.sh
 Last 10 lines of output were:
+ '[' -n 'SHELLOPTS=braceexpand:hashall:interactive-comments:xtrace
if [ -n "$(set | grep xtrace)" ]; then
local enable_xtrace='\''yes'\'';
if [ -n "${enable_xtrace}" ]; then' ']'
+ set +x


| Install r10k  
   |


+ gem install fast_gettext -v '< 1.2.0'
openstack/puppet-openstack-integration/install_modules.sh: line 29: 
gem: command not found

It seems like that the box beaker is using (puppetlabs/ubuntu-14.04-64-nocm), 
somehow ends up with has puppet 4.x installed. I could not exactly pin down how 
this happens, cause when i sin up some VM just from that base box and install 
puppet, i end up with 3.4. But during the beaker tests it ends up with puppet 4 
and in puppet 4 some paths have changed. /opt/puppetlabs/bin is just for the 
'public' applications and the ‘private' ones like gem or ruby are in 
/opt/puppetlabs/puppet/bin. Therefore the 
openstack/puppet-openstack-in​tegration/install_modules.sh script fails on 
installation of r10k, cause it cannot find gem and later on it fails on the 
r10k call cause it is also installed to /opt/puppetlabs/puppet/bin.
Symlinking gem and r10k in an provisioned machine, and rerun the tests fixes 
the problem. Currently i am doing all this cause i added some functionalities 
for the puppet-cep manifests to support bluestone/rocksdb and some additional 
config params which i would like to see in upstream.


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

Re: [openstack-dev] [all] Small steps for Go

[Trinath Somanchi]

+1 , please add me.

/Trinath

Get Outlook for iOS


From: Davanum Srinivas 
Sent: Tuesday, March 7, 2017 6:47:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all] Small steps for Go

Folks,

Anyone interested? https://etherpad.openstack.org/p/go-and-containers

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
__
OpenStack Development Mailing 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] Small steps for Go

[Davanum Srinivas]

Folks,

Anyone interested? https://etherpad.openstack.org/p/go-and-containers

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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Sean McGinnis]

On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> > On 2017-03-06 14:03, Sean Dague  wrote:
> >> I'm trying to understand the implications of
> >> https://review.openstack.org/#/c/439500. And the comment in the linked
> >> email:
> >>
> >> ">> Yes, we decided some time ago to not translate the log files anymore 
> >> and
>  thus our tools do not handle them anymore - and in general, we remove
>  these kind of files."
> >>
> >> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> >> fully removed? Nova currently enforces those things are there -
> >> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> >> and want to make sure our tools aren't making us do work that the i18n
> >> team is ignoring and throwing away.
> > 

So... just looking for a definitive statement on this since there has
been some back and forth discussion.

Is it correct to say - all projects may (should?) now remove all bits in
place for using and enforcing the _Lx() translation markers. Only _()
should be used for user visible error messages.

Sean (smcginnis)


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

Re: [openstack-dev] [tricircle]reschedule the weekly meeting

[joehuang]

Hello,

The patch was merged, the weekly meeting
will be held on UTC 1400 ~ UTC 1500 every
Wednesday from this week.

Best Regards
Chaoyi Huang(joehuang)
发件人：黄朝意
收件人：openstack-dev,Morales, 
Victor,sindhu.dev...@intel.com,prince.a.owusu.boat...@intel.com
时间：2017-03-06 10:07:14
主题:RE: [openstack-dev][tricircle]reschedule the weekly meeting

Hello,

According to the poll[1], the weekly meeting will be rescheduled to UTC 1400 ~ 
UTC 1500 every Wednesday, once the patch[2] was merged, we can start the weekly 
meeting at new time slot.

[1]poll of weekly meeting time: http://doodle.com/poll/hz436r6wm99h4eka#table
[2]new weekly meeting time patch: https://review.openstack.org/#/c/441727/

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 01 March 2017 11:59
To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; 
prince.a.owusu.boat...@intel.com
Subject: RE: [openstack-dev][tricircle]reschedule the weekly meeting

Hello, team,

According to the discussion in the IRC, we'd like to move the weekly meeting 
from UTC1300 to UTC1400, there are several options for this time slot, please 
vote before next Monday, then I'll submit a patch to occupy the new time slot 
and release the old time slot.

Poll link: http://doodle.com/poll/hz436r6wm99h4eka

Note: before the new weekly meeting time is settled, we have to have weekly 
meeting at old time slot.

Best Regards
Chaoyi Huang (joehuang)

From: joehuang
Sent: 27 February 2017 21:48
To: openstack-dev; victor.mora...@intel.com; sindhu.dev...@intel.com; 
prince.a.owusu.boat...@intel.com
Subject: [openstack-dev][tricircle]reschedule the weekly meeting

Hello,

Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 
every Wednesday, it's not convenient for contributors from USA.

The available time slots could be found at
https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0

Other contributors are mostly from East Asia, the time zone is around 
UTC+8/UTC+9.

Please propose some your preferred time slots, and then let's have a poll for 
the new weekly meeting time.

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

Re: [openstack-dev] [all] Discount codes for ATCs

[Jeremy Stanley]

On 2017-03-07 09:54:25 +0100 (+0100), j.kl...@cloudbau.de wrote:
[...]
> So how should i take this? ATCs who can afford to travel to the
> PTG receive more discount/funding from the foundation than ATCs
> who can not afford to go there? I am pretty sad about the
> direction we seem to move with this and am hoping that this will
> only be true for the Boston summit.
[...]

I won't presume to speak for the event staff on this one, but my
understanding is that the summit registration discounts provided to
technical contributors in past years were intended to make it easier
for enough of them to attend the design summit (which ran coincident
with the conference). Now there is no design summit, and most of
what used to take place in that context is expected to happen at the
PTG instead. Funding was redirected toward making the PTG as
inexpensive as possible, and the original plan (up until last week)
was that no separate conference discounts were budgeted for
technical contributors who had not attended the PTG.

The goal is to have as many active technical contributors as
possible attend the PTG events, but we still need a representative
contingent of upstream developers (perhaps 50%?) in attendance for
the "Forum" (which now happens as part of the conference) so as to
be able to effectively collect and respond to feedback from
downstream consumers, end users, operators, et cetera. Because we've
only had one PTG up to this point and it's realized that a lot of
contributors may have been unable to make it to a PTG so far, budget
was found to cover half the conference registration cost for
non-PTG-attendee technical contributors in the Ocata development
cycle.

So knowing what I know, I would take it as a sign that attending the
PTG is strongly encouraged for those heavily involved in upstream
development, and developers who can only afford to go to one of
either the conference or PTG should prefer the PTG. In the future I
anticipate that you'll get partial or full discounted conference
admission if you've attended one of the past two (or three or
something) PTGs, but that technical contributors who are only
interested in attending the conference and not the PTGs will
probably be expected to pay full admission prices regardless of
whether they have changes landed in an official deliverable repo (or
have admission covered in other ways such getting a conference talk
accepted).
-- 
Jeremy Stanley

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

[openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Thierry Carrez]

Hi everyone,

I recently got more information about the space dedicated to the "Forum"
at the OpenStack Summit in Boston. We'll have three different types of
spaces available.

1/ "Forum" proper

There will be 3 medium-sized fishbowl rooms for cross-community
discussions. Topics for the discussions in that space will be selected
and scheduled by a committee formed of TC and UC members, facilitated by
Foundation staff members. In case you missed it, the brainstorming for
topics started last week, announced by Emilien in that email:

http://lists.openstack.org/pipermail/openstack-dev/2017-March/113115.html

2/ "On-boarding" rooms

We'll have two rooms set up in classroom style, dedicated to project
teams and workgroups who want to on-board new team members. Those can
for example be booked by project teams to run an introduction to their
codebase to prospective new contributors, in the hope that they will
join their team in the future. Those are not meant to do traditional
user-facing "project intro" talks -- there is space in the conference
for that. They are meant to provide the next logical step in
contributing after Upstream University and being involved on the
sidelines. It covers the missing link for prospective contributors
between attending Summit and coming to the PTG. Kendall Nelson and Mike
Perez will soon announce the details for this, including how projects
can sign up.

3/ Free hacking/meetup space

We'll have four or five rooms populated with roundtables for ad-hoc
discussions and hacking. We don't have specific plans for these -- we
could set up something like the PTG ethercalc for teams to book the
space, or keep it open. Maybe half/half.

More details on all this as they come up.
Hoping to see you there !

-- 
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] ask.openstack.org site is down!

[Jeremy Stanley]

On 2017-03-07 09:46:12 +0200 (+0200), Abed Abu-Dbai wrote:
[blank message body]

The site seems up to me at this point, but we've been tracking
periodic outages of the service which come some days around the same
timeframe you sent your message today. At this point those of us
investigating still aren't certain what the underlying cause is
(logs don't show anything out of the ordinary, cronjobs on the
server don't seem to be consuming an undue amount of system
resources at that time, et cetera) but we're continuing to look into
it.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [ironic] OpenStack client default ironic API version

[Jim Rollenhagen]

On Tue, Mar 7, 2017 at 6:36 AM, Dmitry Tantsur  wrote:

> On 03/07/2017 12:32 PM, Miles Gould wrote:
>
>> On 06/03/17 20:46, Mario Villaplana wrote:
>>
>>> We also still have yet to decide what a suitable deprecation period is
>>> for this change, as far as I'm aware. Please respond to this email
>>> with any suggestions on the deprecation period.
>>>
>>
>> One cycle?
>>
>
> I'd go with standard deprecation period of MAX(next cycle, 3 months).
> Pinning the version in your environment variables is quite trivial.


I'm also good with the standard deprecation period for this.

Reasoning about the "max" logic here made my brain hurt a bit, probably
just lack of coffee. But to be clear to anyone that is unfamiliar, the
deprecation period must include a cycle boundary and also span at least
three months. This is described in governance docs:
https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html

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

Re: [openstack-dev] [all] [api] API-WG PTG recap

[Dulko, Michal]

On Fri, 2017-03-03 at 17:12 +, Chris Dent wrote:



> 
> # Capabilities Discovery
> 
> https://etherpad.openstack.org/p/capabilities-pike
> 
> This began as an effort to refine a proposed guideline for
> expressing what a cloud can do:
> 
>  https://review.openstack.org/#/c/386555/
> 
> That was modeled as what a cloud can do, what a type of resource in
> that cloud can do, and what this specific instance of this resource
> can do.
> 
> Discussion was wide ranging but eventually diverged into two
> separate directions:
> 
> * Expressing cloud-level capabilities (e.g., does this cloud do floating
>    ips) at either the deployment or service level. The use of the
>    URL /capabilities is in the original spec, but since swift already
>    provides an implementation of an idea like this at /info we should
>    go with that. It's not clear what the next steps with this are,
>    other than to iterate the spec. We need volunteers to work on at
>    least reviewing that, and perhaps picking up the authorship.

Unfortunately I won't be able to dedicate time to the spec in nearest
timeframe. Anyone can feel free to grab it and update it with PTG's
decisions.

> 
> 
> * Satisfying the use case that prompted the generic idea above:
>    Making the right buttons show up in dashboards like horizon that
>    indicate whether or not an instance can be snapshotted and other
>    similar features.
> 
> The next steps on that latter direction are to modify the server
> info representation in the compute api to include a new key which
> answers the top 5 questions that horizon wants to be able to answer.
> Once we see how well that's working, move on.
> 
__
OpenStack Development Mailing 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] OpenStack client default ironic API version

[Dmitry Tantsur]

On 03/07/2017 12:32 PM, Miles Gould wrote:

On 06/03/17 20:46, Mario Villaplana wrote:

We also still have yet to decide what a suitable deprecation period is
for this change, as far as I'm aware. Please respond to this email
with any suggestions on the deprecation period.


One cycle?


I'd go with standard deprecation period of MAX(next cycle, 3 months). Pinning 
the version in your environment variables is quite trivial.




Miles

__
OpenStack Development Mailing 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] OpenStack client default ironic API version

[Miles Gould]

On 06/03/17 20:46, Mario Villaplana wrote:

We also still have yet to decide what a suitable deprecation period is
for this change, as far as I'm aware. Please respond to this email
with any suggestions on the deprecation period.


One cycle?

Miles

__
OpenStack Development Mailing 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] [Sahara][infra] Jenkins based 3rd party CIs

[Luigi Toscano]

On Monday, 6 March 2017 20:05:18 CET James E. Blair wrote:
> Telles Nobrega  writes:
> > Hello,
> > 
> > we from Sahara use the compatibility layer with Zuulv2.5 and we are
> > wondering if with the change to Zuulv3 this compatibility layer will still
> > be maintained.
> > If the layer is removed it will reflect into some changes on our side and
> > we are looking for this information to identify how much work will be
> > needed on our CI.
> 
> Hi,
> 
> If you are referring to the ability to run jobs in Jenkins, no, Zuul
> will no longer have direct support for that.


Hi,
just to be more clear: does it affect 3rd-party CIs still using Jenkins?

The current Sahara CI (see 
http://git.openstack.org/cgit/openstack/sahara-ci-config) uses Jenkins and a 
local Zuul installation. 

I have to admit I lack some knowledge on how much the job triggering is 
connected to the main instance, so apologize for the stupid question: if we 
keep our configuration as it is now, will it continue to work?

(not talking about the convenience of switching to zuul v3, as 2.x is going to 
be unmaintained, this is just to set the priorities).

-- 
Luigi

__
OpenStack Development Mailing 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][Containers] Containers work tracking, updates and schedule

[Flavio Percoco]

Greetings,

We've been organizing the containers work for TripleO in a more consumable way
that will hopefully ease the engagement from different squads and teams in
OpenStack.

The result of this work is all in this etherpad[0], which we'll use as a central
place to keep providing updates and collecting information about the containers
effort. The etherpad is organized as follows:

* One section defining the goals of the effort and its evolution
* One section listing bugs that are critical (in addition to the link querying
 all the bugs tagged as `containers`)
* RDO Tasks are tasks specific for the RDO upstream community (like working on a
 pipeline to build containers)
* One section dedicated to CI's schedule. Tasks we've pending and when they
 should be completed.
* One section for general overcloud tasks grouped by milestone
* One section for review links. This section has been split into smaller groups
 to make reviews easier.
* One section with the list of services that still have to be containerized

We'll keeping this etherpad updated but we'll be also providing updates to the
mailing list with more frequency.

[0] https://etherpad.openstack.org/p/tripleo-composable-containers-overcloud

Let us know if you need anything,
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] [Neutron] ImportError: No module named neutron_lib

[Neil Jerram]

Hi Sam,

On Tue, Mar 7, 2017 at 8:05 AM Sam  wrote:

> Is this?
>
> https://pypi.python.org/pypi/neutron-lib
>

Yes, that is one of the ways that neutron-lib is packaged.  The 'upstream'
is at http://git.openstack.org/cgit/openstack/neutron-lib.

Exactly how are you using the Neutron code?  If you are starting from a git
clone and running Neutron code/tests on your own machine, you should
normally do that within one of the virtual environments that is set up by
'tox', and that process would pull in the neutron-lib code for you.

Best wishes,
 Neil



>
> 2017-03-07 15:48 GMT+08:00 Sam :
>
> Hi,
>
> I'm using neutron mitaka version, I found lots of files include this:
> "from neutron_lib import exceptions as e"
> But I don't find where is neutron_lib, and I got error as "ImportError: No
> module named neutron_lib"
>
> Is there some error?
>
>
> __
> OpenStack Development Mailing 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] [oslo_reports]Does GMR work for uwsgi mode service?

[Roman Podoliaka]

Hi,

My understanding is that it's not recommended for WSGI apps to set up
custom signal handlers. The reason for that is that a WSGI server
(i.e. uwsgi in your case or Apache+mod_wsgi) will most likely have its
own handlers for the very same set of signals [1].

There is an alternative way to trigger a generation of a report by
changing a file modification date [2].

Thanks,
Roman

[1] 
https://code.google.com/archive/p/modwsgi/wikis/ConfigurationDirectives.wiki#WSGIRestrictSignal
[2] https://review.openstack.org/#/c/260976/

On Tue, Mar 7, 2017 at 8:02 AM, hao wang  wrote:
> Hi, stackers,
>
> I'm trying to use Guru Meditation Report in Zaqar project which can
> support uwsgi server.  I imported gmr and used
> "gmr.TextGuruMeditation.setup_autorun(version, conf=conf)",  but it
> didn't work under uwsgi mode.
>
> Did I do something wrong,  or  GMR doesn't support uwsgi mode yet?
>
> Thanks for your help!
>
> Wang Hao
>
> __
> OpenStack Development Mailing 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] Stepping down from Neutron roles

[Miguel Angel Ajo Pelayo]

Nate, it was a pleasure working with you, you and your team made great
contributions to OpenStack and neutron. I'll be very happy if we ever have
the chance to work again together.

Best regards, and very good luck, my friend.

On Tue, Mar 7, 2017 at 4:55 AM, Kevin Benton  wrote:

> Hi Nate,
>
> Thanks for all of your contributions and good luck in your future
> endeavors! You're always welcome back. :)
>
>
> On Mar 6, 2017 13:15, "Nate Johnston"  wrote:
>
> All,
>
> I have been delaying this long enough... sadly, due to changes in
> direction I
> am no longer able to spend time working on OpenStack, and as such I need to
> resign my duties as Services lieutenant, and liaison to the Infra team.  My
> time in the Neutron and FWaaS community has been one of the most rewarding
> experiences of my career.  Thank you to everyone I met at the summits and
> who
> took the time to work with me on my contributions.  And thank you to the
> many
> of you who have become my personal friends.  If I see an opportunity in the
> future to return to OpenStack development I will jump on it in a hot
> minute.
> But until then, I'll be cheering you on from the sidelines.
>
> All the best,
>
> --N.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] - Best release to upgrade from LBaaS v1 to v2

[Saverio Proto]

Hello,

I am upgrading from Mitaka to Newton.

our Openstack cloud has in production LBaaSv1.

I read all the following release notes:

https://docs.openstack.org/releasenotes/neutron/liberty.html
https://docs.openstack.org/releasenotes/neutron/mitaka.html
https://docs.openstack.org/releasenotes/neutron/newton.html

In the liberty release notes I read:
"The LBaaS V1 API is marked as deprecated and is planned to be removed
in a future release. Going forward, the LBaaS V2 API should be used."

But which one is the release that drops LBaaS V1 ?

I see this script is merged in stable/newton:

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

Can I still use LBaaS V1 in newton and do the migration before upgrading
to Ocata ?

The cherry-pick to Mitaka was abandoned:
https://review.openstack.org/#/c/370103/

The Ocata release notes again dont say anything about LBaaS:
https://docs.openstack.org/releasenotes/neutron/ocata.html

thank you

Saverio



-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing 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] Discount codes for ATCs

[j.kl...@cloudbau.de]

Hi,

i just received a discount code for the Boston summit as an ATC for 300$ (while 
the ticket price is currently at 600$). As far as i know every ATC who went to 
the PTG received a discount code of 600$ (also stated here 
https://www.openstack.org/summit/boston-2017/faq/). So how should i take this? 
ATCs who can afford to travel to the PTG receive more discount/funding from the 
foundation than ATCs who can not afford to go there? I am pretty sad about the 
direction we seem to move with this and am hoping that this will only be true 
for the Boston summit.

Cheers,
Jan

PS: Probably someone also wants to change the FAQ text here 
(https://www.openstack.org/summit/boston-2017/faq/) which states: 'No “ATC” 
codes will be distributed for the Boston Summit.”__
OpenStack Development Mailing 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] [picasso] First meeting on 7th of March

[Robert Putt]

Good morning / afternoon / evening,

Not sure if you have seen the agenda etherpad posted in the Slack channel - 
https://etherpad.openstack.org/p/picasso-first-meeting. Might be worth putting 
our thoughts in there, I already had a few questions about integration with the 
OpenStack community and so on.

Here are a few of my biggest sticking points with the project which I feel we 
should really address early on:


a)   Currently the project does not appear to use the standard OpenStack 
Oslo libraries and as such the configuration and behavior of the project is 
inconsistent with other projects. This could be particularly confusing for 
operators as even simple things like the config file (there isn’t one yet that 
I am aware of, stuff is passed In via args at daemon run time) is completely 
different to the usual section based config files we see in most OpenStack 
projects.

b)   The project only works with IronFunctions, not saying that 
IronFunctions is a bad choice for sure a driver for IronFunctions should be 
included, but it would be good to allow other Function as a Service platforms 
to make use of Picasso in a pluggable fashion, e.g. a driver for Fission, or a 
raw driver based on top of Nova / Heat. For me vendor neutrality is a really 
important aspect of OpenStack services and having the freedom to choose the 
backend of these APIs is crucial.

Best Regards,

Rob

From: Derek Schultz 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, March 7, 2017 at 5:19 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [picasso] First meeting on 7th of March

Update: the patch to openstack-infra/irc-meetings was merged, so we should be 
good to go. The only change was moving the meeting time from 1800 UTC to 1700 
UTC.

Meeting details can be found here 
https://wiki.openstack.org/wiki/Meetings/Picasso

On Mon, Mar 6, 2017 at 6:45 PM Derek Schultz 
> wrote:
All good points, it's important that we do not diverge from the community. 
Today I created an #openstack-functions channel on IRC and have submitted the 
necessary patches to the openstack-infra project-config and irc-meetings 
repositories. Due to this, I may have to move the first meeting from this 
Tuesday to another day or week as we wait for approval.. I'll keep this thread 
posted as soon as I know more.

Regards,
Derek

On Thu, Mar 2, 2017 at 11:54 AM Paul Belanger 
> wrote:
On Thu, Mar 02, 2017 at 05:41:24PM +, Derek Schultz wrote:
> Hi Emilien,
>
> Thanks for the feedback! I'm aware that IRC is the standard for OpenStack
> folks, but at this current stage it's just easier to hold the discussion in
> Slack as Picasso ties into the IronFunctions open source project and
> important context would be lost if we were to maintain different chat
> platforms. That said, I think we can move Picasso from Slack to IRC in the
> future (once we prepare for the big tent).
>
I agree with Emilien here, by using a proprietary platform you are potentially
alienation existing openstack developers from contributing to your project.
Yes IRC would be needed for big tent, but why start consuming IRC out of the
gate?

Are are already hosting code on git.openstack.org, 
seems like the next step
would be to move to IRC.

> Regards,
> Derek Schultz
>
> On Wed, Mar 1, 2017 at 7:49 AM Emilien Macchi 
> > wrote:
>
> > On Tue, Feb 28, 2017 at 12:30 PM, Derek Schultz 
> > >
> > wrote:
> > > Hello all,
> > >
> > > The Picasso team will be running our first meeting next Tuesday. All
> > those
> > > interested in the project are welcome!
> > >
> > > For those of you not familiar with Picasso, it provides a platform for
> > > Functions as a Service (FaaS) on OpenStack [1].
> > >
> > > Tuesday, March 7th, 2017 Meeting Agenda:
> > > Starting at UTC 18:00
> > >
> > > 1. From Python to Go. (What Picasso needs from IronFunctions to implement
> > > multi-tenancy)
> > > 2. Blueprints [2]
> > > 3. Figure out best time slot for future meetings.
> > > 4. Roadmap discussion.
> > >
> > > How to join:
> > > http://slack.iron.io in the #openstack channel
> >
> > I would recommend using IRC for consistency with other projects.
> > Nothing forces you to do so, unless you plan to apply to the Big Tent.
> > My personal recommendation would be to use IRC so you can get more
> > visibility, since most of OpenStack folks are on IRC (and not always
> > on Slack).
> >
> > Good luck for your first meeting!
> >
> > > Etherpad:  https://etherpad.openstack.org/p/picasso-first-meeting
> > >
> > > [1] https://wiki.openstack.org/wiki/Picasso
> > > [2] 

Re: [openstack-dev] [Neutron] ImportError: No module named neutron_lib

[Sam]

Is this?

https://pypi.python.org/pypi/neutron-lib

2017-03-07 15:48 GMT+08:00 Sam :

> Hi,
>
> I'm using neutron mitaka version, I found lots of files include this:
> "from neutron_lib import exceptions as e"
> But I don't find where is neutron_lib, and I got error as "ImportError: No
> module named neutron_lib"
>
> Is there some error?
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev