[openstack-dev] [machine learning] Question: Why there is no serious project for machine learning ?

[严超]

Hi, all,
I'm wondering if there is a serious project for machine learning in
Openstack ? For us to easily build a model in industrial operational level.

Thanks,
Andy Yan
__
OpenStack Development Mailing 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] [vitrage] code organization for trace generator and

[Yujun Zhang]

Hi, Root Causers

In the implementation of static driver unit test, the most difficult part
I've encountered is the mock driver and trace generator.

Is there any particular reason to put all mock driver and transformer specs
in the same file `trace_generator.py` and `mock_driver.py`? Would it be
easier to maintain and extend if we organize the specs and drivers in
datasource, e.g. `mock.static`, `mock.nova.host` and etc?

--
Yujun
__
OpenStack Development Mailing 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] Confusion around the complexity

[Joshua Harlow]

Kevin Benton wrote:

If you don't want users to specify network details, then use the get me
a network extension or just have them boot to a public (or other
pre-created) network.

In your thought experiment, why is your iPhone app developer not just
using a PaaS that handles instance scaling, load balancing and HA? Why
would he/she want to spend time managing security updates and log
rotation for an operating system running inside another program
pretending to be hardware? Different levels of abstraction solve
different use cases.


Fair point, probably mr/mrs iPhone app developer should be doing that.



Amazon VPC exists (and is the default) for the same reason neutron
provides network virtualization primitives. People moving legacy apps
onto these systems end up needing specific addressing schemes and
isolation topologies.



What's a legacy app, sounds sorta dirty lol

__
OpenStack Development Mailing 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] [daisycloud-core] Agenda for IRC meeting 0800UTC Jan. 13 2017

[hu . zhijiang]

Sorry for providing the agenda late.

1) Roll Call
2) OPNFV: Daisy CI Progress
3) OPNFV: Daisy Support Escalator
4) OpenStack: Kolla Image Versioning 
5) AoB

B.R.,
Zhijiang



__
OpenStack Development Mailing 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] [ocatvia]Newton Octavia multinode setup

[Santhosh Fernandes]

Hi all,

Is there any documentation or ansible playbook to install octavia on
multi-node or all-in-one setup?
I am trying to setup in my lab but not able to find any documentation.


Thanks,
Santhosh
__
OpenStack Development Mailing 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] Confusion around the complexity

[Kevin Benton]

If you don't want users to specify network details, then use the get me a
network extension or just have them boot to a public (or other pre-created)
network.

In your thought experiment, why is your iPhone app developer not just using
a PaaS that handles instance scaling, load balancing and HA? Why would
he/she want to spend time managing security updates and log rotation for an
operating system running inside another program pretending to be hardware?
Different levels of abstraction solve different use cases.

Amazon VPC exists (and is the default) for the same reason neutron provides
network virtualization primitives. People moving legacy apps onto these
systems end up needing specific addressing schemes and isolation
topologies.


On Jan 12, 2017 20:59, "Joshua Harlow"  wrote:

Sean M. Collins wrote:

> Joshua Harlow wrote:
>
>> So I don't want to start to much of a flame-war and am really just trying
>> to
>> understand things that may be beyond me (so treat me nicely, ha).
>>
>> The basic question that I've been wondering revolves around the following
>> kind of 'thought experiment' that asks something along the lines of:
>>
>> """
>> If I am a user of openstack, say I'm an iphone developer, trying to get my
>> 'game' and associated 'game APIs' setup in a manner that is HA (say
>> fronted
>> by a load-balancer), using my custom image, secure and visible to either
>> an
>> intranet or to the large internet then what is the steps I would have to
>> do
>> when interacting with openstack to accomplish this and what would the
>> provider of openstack have to give to me as endpoints to make this
>> possible.
>> """
>>
>
>
> We have a guide that sort of fits this usecase:
>
> http://developer.openstack.org/firstapp-libcloud/
>
> The networking section, can always use improvement:
>
> http://developer.openstack.org/firstapp-libcloud/networking.html
>
>
Interesting good to know that this exists; though I still have this weird
gut feeling that the following isn't really what people want to be doing
(though they may have to just because that is what it is):

$ openstack network list
$ openstack network create worker_network
$ openstack network create webserver_network
$ openstack subnet create webserver_subnet --network webserver_network
--subnet-range 10.0.2.0/24
$ openstack network create api_network
$ openstack subnet create api_subnet --network api_network --subnet-range
10.0.3.0/24
$ openstack floating ip create public (1st floating IP)
$ openstack floating ip create public (2nd floating IP)
$ openstack router create project_router
$ openstack router set project_router --external-gateway public
$ openstack router add subnet project_router worker_subnet
$ openstack router add subnet project_router api_subnet
$ openstack router add subnet project_router webserver_subnet

And then:

$ nova boot --flavor m1.tiny --image cirros-0.3.3-x86_64-disk --nic
net-id=953224c6-c510-45c5-8a29-37deffd3d78e worker1

ANNND then:

$ openstack network list
$ nova boot --flavor 1 --image 53ff0943-99ba-42d2-a10d-f66656372f87
--min-count 2 test
$ openstack floating ip create public --fixed-ip-address 10.0.0.2 --port
523331cf-5636-4298-a14c-f545bb32abcf
$ openstack floating ip create public --fixed-ip-address 10.0.2.4 --port
462c92c6-941c-48ab-8cca-3c7a7308f580
$ neutron lb-member-create --address 203.0.113.21 --protocol-port 80 mypool
$ neutron lb-member-create --address 203.0.113.22 --protocol-port 80 mypool

AN then:

... (how many more are there, woah)







__
OpenStack Development Mailing 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] Confusion around the complexity

[Joshua Harlow]

Sean M. Collins wrote:

Joshua Harlow wrote:

So I don't want to start to much of a flame-war and am really just trying to
understand things that may be beyond me (so treat me nicely, ha).

The basic question that I've been wondering revolves around the following
kind of 'thought experiment' that asks something along the lines of:

"""
If I am a user of openstack, say I'm an iphone developer, trying to get my
'game' and associated 'game APIs' setup in a manner that is HA (say fronted
by a load-balancer), using my custom image, secure and visible to either an
intranet or to the large internet then what is the steps I would have to do
when interacting with openstack to accomplish this and what would the
provider of openstack have to give to me as endpoints to make this possible.
"""



We have a guide that sort of fits this usecase:

http://developer.openstack.org/firstapp-libcloud/

The networking section, can always use improvement:

http://developer.openstack.org/firstapp-libcloud/networking.html



Interesting good to know that this exists; though I still have this 
weird gut feeling that the following isn't really what people want to be 
doing (though they may have to just because that is what it is):


$ openstack network list
$ openstack network create worker_network
$ openstack network create webserver_network
$ openstack subnet create webserver_subnet --network webserver_network 
--subnet-range 10.0.2.0/24

$ openstack network create api_network
$ openstack subnet create api_subnet --network api_network 
--subnet-range 10.0.3.0/24

$ openstack floating ip create public (1st floating IP)
$ openstack floating ip create public (2nd floating IP)
$ openstack router create project_router
$ openstack router set project_router --external-gateway public
$ openstack router add subnet project_router worker_subnet
$ openstack router add subnet project_router api_subnet
$ openstack router add subnet project_router webserver_subnet

And then:

$ nova boot --flavor m1.tiny --image cirros-0.3.3-x86_64-disk --nic 
net-id=953224c6-c510-45c5-8a29-37deffd3d78e worker1


ANNND then:

$ openstack network list
$ nova boot --flavor 1 --image 53ff0943-99ba-42d2-a10d-f66656372f87 
--min-count 2 test
$ openstack floating ip create public --fixed-ip-address 10.0.0.2 --port 
523331cf-5636-4298-a14c-f545bb32abcf
$ openstack floating ip create public --fixed-ip-address 10.0.2.4 --port 
462c92c6-941c-48ab-8cca-3c7a7308f580

$ neutron lb-member-create --address 203.0.113.21 --protocol-port 80 mypool
$ neutron lb-member-create --address 203.0.113.22 --protocol-port 80 mypool

AN then:

... (how many more are there, woah)






__
OpenStack Development Mailing 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] Confusion around the complexity

[Sean M. Collins]

Joshua Harlow wrote:
> So I don't want to start to much of a flame-war and am really just trying to
> understand things that may be beyond me (so treat me nicely, ha).
> 
> The basic question that I've been wondering revolves around the following
> kind of 'thought experiment' that asks something along the lines of:
> 
> """
> If I am a user of openstack, say I'm an iphone developer, trying to get my
> 'game' and associated 'game APIs' setup in a manner that is HA (say fronted
> by a load-balancer), using my custom image, secure and visible to either an
> intranet or to the large internet then what is the steps I would have to do
> when interacting with openstack to accomplish this and what would the
> provider of openstack have to give to me as endpoints to make this possible.
> """


We have a guide that sort of fits this usecase:

http://developer.openstack.org/firstapp-libcloud/

The networking section, can always use improvement:

http://developer.openstack.org/firstapp-libcloud/networking.html

-- 
Sean M. Collins

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

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

[Takashi Yamamoto]

hi,

On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> Hi
>
> As of today, the project neutron-vpnaas is no longer part of the neutron
> governance. This was a decision reached after the project saw a dramatic
> drop in active development over a prolonged period of time.
>
> What does this mean in practice?
>
> From a visibility point of view, release notes and documentation will no
> longer appear on openstack.org as of Ocata going forward.
> No more releases will be published by the neutron release team.
> The neutron team will stop proposing fixes for the upstream CI, if not
> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>
> How does it affect you, the user or the deployer?
>
> You can continue to use vpnaas and its CLI via the python-neutronclient and
> expect it to work with neutron up until the newton
> release/python-neutronclient 6.0.0. After this point, if you want a release
> that works for Ocata or newer, you need to proactively request a release
> [5], and reach out to a member of the neutron release team [3] for approval.

i want to make an ocata release. (and more importantly the stable branch,
for the benefit of consuming subprojects)
for the purpose, the next step would be ocata-3, right?

> Assuming that the vpnaas CI is green, you can expect to have a working
> vpnaas system upon release of its package in the foreseeable future.
> Outstanding bugs and new bug reports will be rejected on the basis of lack
> of engineering resources interested in helping out in the typical OpenStack
> review workflow.
> Since we are freezing the development of the neutron CLI in favor of the
> openstack unified client (OSC), the lack of a plan to make the VPN commands
> available in the OSC CLI means that at some point in the future the neutron
> client CLI support for vpnaas may be dropped (though I don't expect this to
> happen any time soon).
>
> Can this be reversed?
>
> If you are interested in reversing this decision, now it is time to step up.
> That said, we won't be reversing the decision for Ocata. There is quite a
> curve to ramp up to make neutron-vpnaas worthy of being classified as a
> neutron stadium project, and that means addressing all the gaps identified
> in [6]. If you are interested, please reach out, and I will work with you to
> add your account to [4], so that you can drive the neutron-vpnaas agenda
> going forward.
>
> Please do not hesitate to reach out to ask questions and/or clarifications.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/392010/
> [2] https://review.openstack.org/#/c/397924/
> [3] https://review.openstack.org/#/admin/groups/150,members
> [4] https://review.openstack.org/#/admin/groups/502,members
> [5] https://github.com/openstack/releases
> [6]
> http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [kolla] Adding jeffrey4l to kolla-kubernetes-core because he is release liason

[Steven Dake (stdake)]

We are busily releasing 0.4.0 of the Kolla deliverable kolla-kubernetes and 
have determined we can’t release the kolla-kubernetes milestone without the 
release liaison for Kolla being on the core reviewer sub-team to make last 
minute fine tuning adjustments to the release and approve other people’s 
changes during crunch time.

The release liaison is one of the most trusted individuals in an OpenStack 
project, as they have ultimate authority over which tags get generated when for 
which deliverables.  If anyone has issue with this change, please raise it 
(since we didn’t do our standard procedural voting for a core reviewer).  If 
folks raise issues with it, inc0 can reverse the change, and we can have a 
standard vote instead which I’m sure would pass.

Regards
-steve

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

Re: [openstack-dev] [tripleo] TripleO Squads - What's next?

[Emilien Macchi]

On Fri, Nov 25, 2016 at 12:51 PM, Emilien Macchi  wrote:
> I'm happy to announce we officially accepted TripleO Squads in our project:
> http://specs.openstack.org/openstack/tripleo-specs/specs/policy/squads.html
>
> We hope it will help us to scale our team and improve our way to work 
> together.
>
> The next steps... I started a new etherpad:
> https://etherpad.openstack.org/p/tripleo-squads
> We'll use it to start building our squads.
>
> Actions to take now:
>
> - If you are a TripleO regular contributor (ie contributing to TripleO
> is part of your daily work), please add your name in the squads.
> - Feel free to adjust the name of the squads, add more squads if
> something is missing. Also, feel free to improve the description, give
> more thoughts about the work done in the squad, etc. This etherpad
> will only be built by the team!
> - For each squad, we need to find a mission statement, that defines
> the scope of work being done.
> - For each squad, we need to find a liaison. The liaison will act as a
> squad lead and PTL will collaborate with liaison first when dealing
> with some work related to the squad. If you volunteer, please put your
> name.
>
> This new squad thing is really new for us, please keep giving feedback
> and propose new ideas,
> Thanks!

I found useful to share a quick status on where TripleO currently
stands with Squads.

https://etherpad.openstack.org/p/tripleo-squads

So far, we have been seeing 4 active squads:

- Upgrades
Regular meeting on Bluejeans where anyone in the community can join
and public notes are published after each meeting.
They have a mission statement and a liaison (marios).

-  CI
Regular meeting on Bluejeans where anyone in the community can join
and public notes are published after each meeting.
We have a mission statement and a liaison (adarazs).

- CLI / UI
I'm not aware about any public meeting yet but if I missed it please correct me.
They don't have a clear mission statement yet and their liaison is jtomasek.

- Containers
No public meeting, no mission statement and no liaison yet.

Other squads mentioned in the etherpad are not really active yet.

Things are moving! That's great. I propose some next steps for the 4
active squads:
- (medium) document who is working in the squads (please put your name
in the etherpad).
- (high) document how to get involved in the Squad. It can be an
etherpad to start or a Wiki page. The idea is to welcome new
contributors in TripleO. Since each squad is specific to an area of
TripleO, we might want to document how to get involved on this area.
What is the knowledge to have before being able to commit. Document
where meetings happen and when, etc.

Please let me know if any help is needed, I would be happy to do so.
Thanks for the folks helping in this move, we hope it will help at
scaling the TripleO team!
-- 
Emilien Macchi

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

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

[Brian Rosmaita]

(Top-posting, don't bother digging through for more.)

We're following the tempest HACKING.rst procedure.  The patch for step
#2 is: https://review.openstack.org/#/c/419658/

Please review at your earliest convenience.

thanks,
brian


On 1/12/17 3:34 PM, Brian Rosmaita wrote:
> Ken,
> 
> Thanks for the quick response ... we'll follow the procedure outlined in
> the tempest HACKING.rst that you pointed out.
> 
> cheers,
> brian
> 
> On 1/12/17 2:32 PM, Ken'ichi Ohmichi wrote:
>> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
>>> On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
>>>
 But from meeting logs, it looks like impression was(if am not wrong) that
 Tempest test[1] is not doing the right thing and should be ok to change.
 I do not think this is the case, Tempest test is doing what API
 tells/behave. Below is what test does:
  1. Tenant A creates image with explicitly visibility as private.
  2. Tenant A add Tenant B as member of created image to allow Tenant B to
 use that.

 API [2] or Image sharing workflow [3] does not say/recommend anywhere that
 Image should not be created with private visibility as explicitly.

 For me this change breaks people "Creating Image with private visibility as
 *explicitly* and adding member to that" which will be 409 after glance
 proposal.


 Also changing tempest tests does not solve the problem, backward
 incompatible is still will be introduced in API.
>>>
>>> The issue is that we are proposing to introduce an incompatible change
>>> in order to address an incoherence with image visibility semantics.  We
>>> have acknowledged that this is a breaking change, but the impact of the
>>> change is mitigated by the way that the default visibility value is
>>> assigned in Ocata.
>>>
>>> As I've documented earlier in the thread, we have discussed this change
>>> with the wider community and the API Working Group, and they are OK with it.
>>>
>>> The current tempest test has done its duty and identified an
>>> incompatibility in the Ocata code.  We acknowledge that and salute you.
>>> On balance, however, this change will be better for users (and as I've
>>> documented earlier in the thread, we've minimized the impact of the
>>> change), and we want to make it anyway.
>>
>> It is difficult to expect the impact of API change is small by us as 
>> developers.
>> For example, if there could be some APPs which list images of both
>> private and shared by depending on
>> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
>> broken after fixing it.
>> Nova team faced such situation we expected the impact of the change
>> was small but horizon was broken, then we reverted the change in the
>> same dev cycle.
>> Then Nova has now API microversions mechanism to avoid impacting to
>> the existing APPs.
>>
>> This is on very difficult balance, and we don't want to block the
>> glance team development.
>> We have some procedure for this situation like
>> https://github.com/openstack/tempest/blob/master/HACKING.rst#2-bug-fix-on-core-project-needing-tempest-changes
>> I did put some comments on https://review.openstack.org/#/c/414261 .
>> Could you check that?
>>
>> Thanks
>> Ken Ohmichi
>>
>> ---
>>
>>> So the situation isn't that we are claiming that your current code is
>>> flawed.  Rather, it is that we are asking the QA team to approve a
>>> change to that test in order to address a change we are making in Ocata,
>>> a change that has the support of the OpenStack community.
>>>
>>> thanks,
>>> brian
>>>

 .. 1
 http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338

 .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
 .. 3
 http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html


 Regards
 Ghanshyam Mann
 +818011120698


 On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
 
 wrote:

> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
>> To anyone interested in this discussion: I put it on the agenda for
>> today's API-WG meeting (16:00 UTC):
>>
>> https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
>
> As you probably noticed in the API-WG newsletter [A], this issue was
> discussed at last week's API-WG meeting.  The complete discussion is in
> the meeting log [B], but the tldr; is that the proposed change is
> acceptable.  I'll address specific points inline for those who are
> interested, but the key request from the Glance team right now is that
> the QA team approve this patch:
>
> https://review.openstack.org/#/c/414261/
>
>
> [A]
> http://lists.openstack.org/pipermail/openstack-dev/2017-
> January/109698.html
> [B]
> http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
> wg.2017-01-05-16.00.log.html

[openstack-dev] [all] [goals] proposing a new goal: "Control Plane API endpoints deployment via WSGI"

[Emilien Macchi]

Greetings OpenStack community,

I have been looking for a Community Goal [1] that would directly help
Operators and I found the "run API via WSGI" useful.
So I've decided to propose this one as a goal for Pike but I'll stay
open to postpone it to Queen if our community thinks we already have
too much goals for Pike.

Note that this goal might help to achieve 2 other goals later:
- enable and test SSL everywhere
- enable and test IPv6 everywhere

Here's the draft:
https://review.openstack.org/419706

Any feedback is very welcome, thanks for reading so far.

[1] https://etherpad.openstack.org/p/community-goals
-- 
Emilien Macchi

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

Re: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20

[joehuang]

Hello, Doug,

One question, according to the guide for self-branch[1], the Ocata stable 
branch should be created for RC1 tag for projects using the 
cycle-with-milestone release model. The date for RC1 one is Jan 30 - Feb 03 
according to the schedule [2]. Tricircle is one big-tent project with  
cycle-with-intermediary mode, and has dependency on stable Neutron, should 
Tricircle Ocata stable branch be created during  Jan 30 - Feb 03 or later than 
Feb 03? I think Neutron Ocata stable branch will be created during Jan 30 - Feb 
03.

[1]http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n66
[2] https://releases.openstack.org/ocata/schedule.html

Best Regards
Chaoyi Huang (joehuang)


From: Doug Hellmann [d...@doughellmann.com]
Sent: 13 January 2017 2:34
To: openstack-dev
Subject: [openstack-dev] [release] Release countdown for week R-5, Jan 16-20

Focus
-

Feature work and major refactoring should be starting to wrap up
as we approach the third milestone and various feature and release
freeze dates.

The deadline for non-client library releases is Thursday 19 Jan.
We do not grant Feature Freeze Extensions for any libraries, so
that is a hard freeze date. Any feature work that requires updates
to non-client libraries should be prioritized so it can be completed
by that time.

Release Tasks
-

As we did at the end of Newton, when the time comes to create
stable/ocata branches they will be configured so that members of
the $project-release group in gerrit have permission to approve
patches.  This group should be a small subset of the core review
team, aware of the priorities and criteria for patches to be approved
as we work toward release candidates. Release liaisons should ensure
that these groups exist in gerrit and that their membership is
correct for this cycle.  Please coordinate with the release management
team if you have any questions.

General Notes
-

We will start the soft string freeze during R-4 (23-27 Jan). See
https://releases.openstack.org/ocata/schedule.html#o-soft-sf for
details

The release team is now publishing the release calendar using ICS.
Subscribe your favorite calendaring software to
https://releases.openstack.org/schedule.ics for automatic updates.

Important Dates
---

Final release of non-client libraries: 19 Jan

Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan

Ocata release schedule: http://releases.openstack.org/ocata/schedule.html

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

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

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

[GHANSHYAM MANN]

On Fri, Jan 13, 2017 at 4:32 AM, Ken'ichi Ohmichi 
wrote:

> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
> > On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
> >
> >> But from meeting logs, it looks like impression was(if am not wrong)
> that
> >> Tempest test[1] is not doing the right thing and should be ok to change.
> >> I do not think this is the case, Tempest test is doing what API
> >> tells/behave. Below is what test does:
> >>  1. Tenant A creates image with explicitly visibility as private.
> >>  2. Tenant A add Tenant B as member of created image to allow Tenant B
> to
> >> use that.
> >>
> >> API [2] or Image sharing workflow [3] does not say/recommend anywhere
> that
> >> Image should not be created with private visibility as explicitly.
> >>
> >> For me this change breaks people "Creating Image with private
> visibility as
> >> *explicitly* and adding member to that" which will be 409 after glance
> >> proposal.
> >>
> >>
> >> Also changing tempest tests does not solve the problem, backward
> >> incompatible is still will be introduced in API.
> >
> > The issue is that we are proposing to introduce an incompatible change
> > in order to address an incoherence with image visibility semantics.  We
> > have acknowledged that this is a breaking change, but the impact of the
> > change is mitigated by the way that the default visibility value is
> > assigned in Ocata.
>

​I am totally agree that the proposed way is really nice improvement but we
should not compensate
the​ breaking change in that. What ever API we provided we have to live
with those until unless it is bug fix.
Improvement in software and mainly APIs are always welcome but they should
not break the users and should be done in versioned way.

The problem here I see is that Glance does not provide any way for users to
discover or pin cloud on what version they want or what they do not. Glance
v2 always default to latest version so all users automatically gets into
the latest changes irrespective of it breaks them and they do not want.

We really do not want to block that visibility improvement proposal but it
should not break users.



> >
> > As I've documented earlier in the thread, we have discussed this change
> > with the wider community and the API Working Group, and they are OK with
> it.
>
​But API-wg guidelines clearly states that below is not acceptable [1]

   - A change such that a request which was successful before now results
   in an error response (unless the success reported previously was hiding an
   existing error condition).

.. 1
https://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
 ​



> >
> > The current tempest test has done its duty and identified an
> > incompatibility in the Ocata code.  We acknowledge that and salute you.
> > On balance, however, this change will be better for users (and as I've
> > documented earlier in the thread, we've minimized the impact of the
> > change), and we want to make it anyway.
>
> It is difficult to expect the impact of API change is small by us as
> developers.
> For example, if there could be some APPs which list images of both
> private and shared by depending on
> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
> broken after fixing it.
> Nova team faced such situation we expected the impact of the change
> was small but horizon was broken, then we reverted the change in the
> same dev cycle.
> Then Nova has now API microversions mechanism to avoid impacting to
> the existing APPs.
>
> ​+1, microversion is a nice solution for that problem. ​



> This is on very difficult balance, and we don't want to block the
> glance team development.
> We have some procedure for this situation like
> https://github.com/openstack/tempest/blob/master/HACKING.
> rst#2-bug-fix-on-core-project-needing-tempest-changes
> I did put some comments on https://review.openstack.org/#/c/414261 .
> Could you check that?
>
> Thanks
> Ken Ohmichi
>
> ---
>
> > So the situation isn't that we are claiming that your current code is
> > flawed.  Rather, it is that we are asking the QA team to approve a
> > change to that test in order to address a change we are making in Ocata,
> > a change that has the support of the OpenStack community.
> >
> > thanks,
> > brian
> >
> >>
> >> .. 1
> >> http://git.openstack.org/cgit/openstack/tempest/tree/
> tempest/api/image/v2/test_images.py#n338
> >>
> >> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
> >> .. 3
> >> http://specs.openstack.org/openstack/glance-specs/specs/
> api/v2/sharing-image-api-v2.html
> >>
> >>
> >> Regards
> >> Ghanshyam Mann
> >> +818011120698
> >>
> >>
> >> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita <
> rosmaita.foss...@gmail.com>
> >> wrote:
> >>
> >>> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
>  To anyone interested in this discussion: I put it on the agenda for
>  today's API-WG meeting (16:00 UTC):
> 
> 

[openstack-dev] What's Up, Doc? 13 January

[Lana Brindley]

Hi everyone,

Welcome to 2017. I hope you all had a chance to rest up a little before we 
hurtle straight into another release, as Ocata is now only 40 days away! I'll 
be in contact with our lovely release managers Brian and Mariia over the next 
week or so to kick off release management tasks. We will need people to test 
the Installation Guide again, too, so if you're interested in helping out 
there, please let me know.

As many of you already know, I'm not planning on running for Pike PTL. PTL 
nominations open in the week of 23 January, and I'll be working with Alex and 
Kato-san who have both expressed interest in taking on this role. If you're 
interested in running for PTL (for Pike or any future release), and would like 
a crash course in PTLing, please let me know and I can share whatever meagre 
wisdom I've gleaned.

== Progress towards Ocata ==

40 days to go!

Closed 149 bugs so far.

Deliverables are being tracked here: 
https://wiki.openstack.org/wiki/Documentation/OcataDeliverables

== The Road to PTG in Atlanta ==

Event info is available here: http://www.openstack.org/ptg 
Purchase tickets here: https://pikeptg.eventbrite.com/ 

Docs is a horizontal project, so our sessions will run across the Monday and 
Tuesday of the event. We will be combining the docs event with i18n, so 
translators and docs people will all be in the room together.

The incoming PTL will be responsible for planning and running sessions at the 
Atlanta PTG.

Also, a quick note that the CFP and ticket sales for *Boston* in May are now 
open: https://www.openstack.org/summit/boston-2017/call-for-presentations/

== Speciality Team Reports ==

* API: Anne Gentle
Fairy-slipper is being retired. It was a good tool, served its purpose, and can 
now traipse into the sunset, thanks to AJaeger and stevemar for the help with 
the patches. Be sure to follow the service catalog naming conventions work 
going on in the API WG. And there's also a new EC2 API reference: 
http://developer.openstack.org/api-ref/ec2-api/ 

* Configuration Reference and CLI Reference: Tomoyuki Kato
Config Reference: Updated a few plug-ins. CLI reference: Updated a few command 
references and removed unsupported Block Storage API v1 and Image API v1.

* High Availability Guide: Andrew Beekhof
No report this week

* Hypervisor Tuning Guide: Joe Topjian
No report this week

* Installation guides: Lana Brindley
Testing for Ocata will be opening soon. Also, we need a web dev for the landing 
page, if you know of anyone, please get me in touch. 

* Networking Guide: John Davidge
No update this week.

* Operations and Architecture Design guides: Darren Chan
Ben Silverman has spent some time refining the Compute content in the Arch 
Guide draft. Thanks Ben! We are also looking for more SMEs to help with the 
Arch Guide. So if you're interested, contact asettle or me.

* Security Guide: Nathaniel Dillon
No update this week.

* Training Guides: Matjaz Pancur
No update this week.

* Training labs: Pranav Salunke, Roger Luethi
No update this week.

* User guides: Joseph Robinson
The command conversions have happened at a good pace, the User Guide appears to 
be mostly complete, with the condition that the trove and manila teams do not 
have OpenStack commands yet. I have started checking through the Admin Guide 
files. I suspect there is more to convert, but it should be ready for Ocata.

== Doc team meeting ==

Our next meeting will be on Thursday 27 January at 2100 UTC in 
#openstack-meeting-alt

For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#13_January_2017

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

Re: [openstack-dev] [neutron] Confusion around the complexity

[Michael Johnson]

Actually we have a single call create for load balancers[1], so I think that
addresses Josh's concern about complexity in the number of required calls.
As for the complexity of the "concept" of a load balancer, I think we have
improved that greatly with the LBaaSv2 API.

That said, if there are things that jump out at you for usability/complexity
please open a bug for us[2].  We welcome the input!

Michael

P.S. Yes, single call create is not in the main API docs, don't ask, yes we
are working on that.

[1]
http://docs.openstack.org/developer/octavia/api/octaviaapi.html#create-fully
-populated-load-balancer
[2] https://bugs.launchpad.net/octavia/+filebug

-Original Message-
From: Curtis [mailto:serverasc...@gmail.com] 
Sent: Thursday, January 12, 2017 3:30 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [neutron] Confusion around the complexity

On Thu, Jan 12, 2017 at 3:46 PM, Joshua Harlow 
wrote:
> So I don't want to start to much of a flame-war and am really just 
> trying to understand things that may be beyond me (so treat me nicely,
ha).
>
> The basic question that I've been wondering revolves around the 
> following kind of 'thought experiment' that asks something along the lines
of:
>
> """
> If I am a user of openstack, say I'm an iphone developer, trying to 
> get my 'game' and associated 'game APIs' setup in a manner that is HA 
> (say fronted by a load-balancer), using my custom image, secure and 
> visible to either an intranet or to the large internet then what is 
> the steps I would have to do when interacting with openstack to 
> accomplish this and what would the provider of openstack have to give to
me as endpoints to make this possible.
> """
>

Presumably this is a public OpenStack cloud? If so...

It's been a while since I worked at a public OpenStack cloud, but most I
would imagine will auto create a tenant network and router (if they can
afford the public IPv4s for the router :)) and then when a user creates an
instance it just ends up on that initial "default" tenant network. This is
usually left to the public cloud to implement during their customer
on-boarding process. That is assuming the public cloud is allowing tenant
"private" networks, which not all would do. There are other models.

Now, a load balancer, if that is required, is different and bit harder if
you mean one that is managed by the OpenStack cloud, as opposed to a user
creating their own LB instance.

Perhaps what you are really thinking about is the simplicity of a more "VPS"
like interface, ala Digital Ocean (and now somewhat mimicked by AWS with uh,
LightSail I think). I've always thought it would perhaps be a nice project
in OpenStack to do a simple VPS style interface.

Thanks,
Curtis.

> One of the obvious ones is nova and glance, and the API and usage 
> there feels pretty straightforward as is (isn't really relevant to 
> this conversation anyway). The one that feels bulky and confusing (at 
> least for
> me) is the things I'd have to do in neutron to create and/or select 
> networks, create and/or select subnets, create and/or select ports and 
> so-on...
>
> As a supposed iphone developer (dev/ops, yadayada) just trying to get 
> his/her game to market why would I really want to know about selecting 
> networks, create and/or selecting subnets, create and/or selecting 
> ports and so-on...
>
> It may just be how it is, but I'd like to at least ask if others are 
> really happy with the interactions/steps (I guess we could/maybe we 
> should ask similar questions around various other projects as well?); 
> if I'm just an outlier that's ok, at least I asked :-P
>
> -Josh
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Blog: serverascode.com

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


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

Re: [openstack-dev] [neutron] Confusion around the complexity

[Curtis]

On Thu, Jan 12, 2017 at 3:46 PM, Joshua Harlow  wrote:
> So I don't want to start to much of a flame-war and am really just trying to
> understand things that may be beyond me (so treat me nicely, ha).
>
> The basic question that I've been wondering revolves around the following
> kind of 'thought experiment' that asks something along the lines of:
>
> """
> If I am a user of openstack, say I'm an iphone developer, trying to get my
> 'game' and associated 'game APIs' setup in a manner that is HA (say fronted
> by a load-balancer), using my custom image, secure and visible to either an
> intranet or to the large internet then what is the steps I would have to do
> when interacting with openstack to accomplish this and what would the
> provider of openstack have to give to me as endpoints to make this possible.
> """
>

Presumably this is a public OpenStack cloud? If so...

It's been a while since I worked at a public OpenStack cloud, but most
I would imagine will auto create a tenant network and router (if they
can afford the public IPv4s for the router :)) and then when a user
creates an instance it just ends up on that initial "default" tenant
network. This is usually left to the public cloud to implement during
their customer on-boarding process. That is assuming the public cloud
is allowing tenant "private" networks, which not all would do. There
are other models.

Now, a load balancer, if that is required, is different and bit harder
if you mean one that is managed by the OpenStack cloud, as opposed to
a user creating their own LB instance.

Perhaps what you are really thinking about is the simplicity of a more
"VPS" like interface, ala Digital Ocean (and now somewhat mimicked by
AWS with uh, LightSail I think). I've always thought it would perhaps
be a nice project in OpenStack to do a simple VPS style interface.

Thanks,
Curtis.

> One of the obvious ones is nova and glance, and the API and usage there
> feels pretty straightforward as is (isn't really relevant to this
> conversation anyway). The one that feels bulky and confusing (at least for
> me) is the things I'd have to do in neutron to create and/or select
> networks, create and/or select subnets, create and/or select ports and
> so-on...
>
> As a supposed iphone developer (dev/ops, yadayada) just trying to get
> his/her game to market why would I really want to know about selecting
> networks, create and/or selecting subnets, create and/or selecting ports and
> so-on...
>
> It may just be how it is, but I'd like to at least ask if others are really
> happy with the interactions/steps (I guess we could/maybe we should ask
> similar questions around various other projects as well?); if I'm just an
> outlier that's ok, at least I asked :-P
>
> -Josh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Blog: serverascode.com

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

[openstack-dev] [neutron] Is anybody using the "next_hop" field in FIP association update notifications?

[Tidwell, Ryan]

Hi all,

In reviewing the change [1], the question arose as to whether any project other 
than neutron-dynamic-routing has been using the "next_hop" field included in a 
callback notification emitted when FIP association is updated [2]. The question 
as to whether to deprecate or simply remove this field has arisen due to the 
history of inclusion of this field in the notification. It was initially 
included to support BGP dynamic routing in Mitaka when it was in-tree. However, 
due to the bug [3] neutron-dynamic-routing no longer requires this field be 
included in the notification and its inclusion now seems to have little value, 
and this value shouldn't really be identified by code inside the neutron repo 
anyway. I wanted to poke the mailing list to give folks a chance to take a look 
and make sure they aren't relying on this. >From what I can tell there are no 
uses of this inside the neutron repo, nor are there any other consumers inside 
the stadium.  For maintainers of stadium projects, could you please confirm or 
debunk my analysis of the situation?

-Ryan Tidwell


[1] https://review.openstack.org/#/c/357722
[2] https://review.openstack.org/#/c/357722/5/neutron/db/l3_db.py@a1182
[3] https://launchpad.net/bugs/1615919

__
OpenStack Development Mailing 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] Confusion around the complexity

[Chris Friesen]

On 01/12/2017 04:46 PM, Joshua Harlow wrote:

So I don't want to start to much of a flame-war and am really just trying to
understand things that may be beyond me (so treat me nicely, ha).

The basic question that I've been wondering revolves around the following kind
of 'thought experiment' that asks something along the lines of:

"""
If I am a user of openstack, say I'm an iphone developer, trying to get my
'game' and associated 'game APIs' setup in a manner that is HA (say fronted by a
load-balancer), using my custom image, secure and visible to either an intranet
or to the large internet then what is the steps I would have to do when
interacting with openstack to accomplish this and what would the provider of
openstack have to give to me as endpoints to make this possible.
"""

One of the obvious ones is nova and glance, and the API and usage there feels
pretty straightforward as is (isn't really relevant to this conversation
anyway). The one that feels bulky and confusing (at least for me) is the things
I'd have to do in neutron to create and/or select networks, create and/or select
subnets, create and/or select ports and so-on...

As a supposed iphone developer (dev/ops, yadayada) just trying to get his/her
game to market why would I really want to know about selecting networks, create
and/or selecting subnets, create and/or selecting ports and so-on...


Nova/neutron now support "get me a network" which can simplify basic setups 
quite a bit.


Also, it's possible that the service provider could have created the 
networks/subnets for you when you initially set up the account, at which point 
you just boot up an instance on the right network.


As for why you would want to deal with the nitty gritty, consider a basic setup 
with a loadbalancer, multiple HTTP servers, and a backend DB.  The loadbalancer 
needs to be on a network that is routable to the public internet.  The HTTP 
servers need to be accessible from the loadbalancer, but we probably don't want 
them visible to the public internet.  The backend DB should only be accessible 
from the HTTP servers, not the loadbalancer, and it definitely shouldn't be on 
the public internet.  So we're talking maybe two separate virtual networks.  In 
real life the DB would probably be HA, so you'd have multiple DB servers (likely 
with their own private network for sync traffic) and maybe another loadbalancer 
in front of them.


Chris

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

Re: [openstack-dev] [neutron] Confusion around the complexity

[Armando M.]

On 12 January 2017 at 15:07, Armando M.  wrote:

>
>
> On 12 January 2017 at 14:46, Joshua Harlow  wrote:
>
>> So I don't want to start to much of a flame-war and am really just trying
>> to understand things that may be beyond me (so treat me nicely, ha).
>>
>> The basic question that I've been wondering revolves around the following
>> kind of 'thought experiment' that asks something along the lines of:
>>
>> """
>> If I am a user of openstack, say I'm an iphone developer, trying to get
>> my 'game' and associated 'game APIs' setup in a manner that is HA (say
>> fronted by a load-balancer), using my custom image, secure and visible to
>> either an intranet or to the large internet then what is the steps I would
>> have to do when interacting with openstack to accomplish this and what
>> would the provider of openstack have to give to me as endpoints to make
>> this possible.
>> """
>>
>> One of the obvious ones is nova and glance, and the API and usage there
>> feels pretty straightforward as is (isn't really relevant to this
>> conversation anyway). The one that feels bulky and confusing (at least for
>> me) is the things I'd have to do in neutron to create and/or select
>> networks, create and/or select subnets, create and/or select ports and
>> so-on...
>
>
>> As a supposed iphone developer (dev/ops, yadayada) just trying to get
>> his/her game to market why would I really want to know about selecting
>> networks, create and/or selecting subnets, create and/or selecting ports
>> and so-on...
>>
>> It may just be how it is, but I'd like to at least ask if others are
>> really happy with the interactions/steps (I guess we could/maybe we should
>> ask similar questions around various other projects as well?); if I'm just
>> an outlier that's ok, at least I asked :-P
>>
>
> Answering your question in a nutshell is very hard, but I'll try
> nonetheless.
>
> I bet that if you think really hard, complications may arise even when
> dealing with images and compute resources. That's because, in the most
> trivial cases you are not thinking about the services that your image must
> provide (and if so you may start injecting user-data into your boot phase)
> or performance requirements you may have (and if so, you may want your
> hypervisors to provide certain optimizations).
>
> IMO, the networking case is inherently complex because the network
> architecture required by a non trivial application is itself complex, in
> that you may need tiers of security, you need to HA, etc. In the most
> trivial case where you just want a single endpoint to which you can talk
> to, there's get-me-a-network [1,2]. You can fire boot a VM on of top of a
> auto-provisioned network topology and off you go. To get external access
> you're only left with a floating IP association, but that's only one API
> call away.
>
> Cheers,
> Armando
>
> [1] https://specs.openstack.org/openstack/neutron-specs/specs/
> liberty/get-me-a-network.html
> [2] http://docs.openstack.org/newton/networking-guide/
> config-auto-allocation.html
>

Forgot to add the nova-side of the spec:

http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/get-me-a-network.html


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

Re: [openstack-dev] [neutron] Confusion around the complexity

[Armando M.]

On 12 January 2017 at 14:46, Joshua Harlow  wrote:

> So I don't want to start to much of a flame-war and am really just trying
> to understand things that may be beyond me (so treat me nicely, ha).
>
> The basic question that I've been wondering revolves around the following
> kind of 'thought experiment' that asks something along the lines of:
>
> """
> If I am a user of openstack, say I'm an iphone developer, trying to get my
> 'game' and associated 'game APIs' setup in a manner that is HA (say fronted
> by a load-balancer), using my custom image, secure and visible to either an
> intranet or to the large internet then what is the steps I would have to do
> when interacting with openstack to accomplish this and what would the
> provider of openstack have to give to me as endpoints to make this possible.
> """
>
> One of the obvious ones is nova and glance, and the API and usage there
> feels pretty straightforward as is (isn't really relevant to this
> conversation anyway). The one that feels bulky and confusing (at least for
> me) is the things I'd have to do in neutron to create and/or select
> networks, create and/or select subnets, create and/or select ports and
> so-on...


> As a supposed iphone developer (dev/ops, yadayada) just trying to get
> his/her game to market why would I really want to know about selecting
> networks, create and/or selecting subnets, create and/or selecting ports
> and so-on...
>
> It may just be how it is, but I'd like to at least ask if others are
> really happy with the interactions/steps (I guess we could/maybe we should
> ask similar questions around various other projects as well?); if I'm just
> an outlier that's ok, at least I asked :-P
>

Answering your question in a nutshell is very hard, but I'll try
nonetheless.

I bet that if you think really hard, complications may arise even when
dealing with images and compute resources. That's because, in the most
trivial cases you are not thinking about the services that your image must
provide (and if so you may start injecting user-data into your boot phase)
or performance requirements you may have (and if so, you may want your
hypervisors to provide certain optimizations).

IMO, the networking case is inherently complex because the network
architecture required by a non trivial application is itself complex, in
that you may need tiers of security, you need to HA, etc. In the most
trivial case where you just want a single endpoint to which you can talk
to, there's get-me-a-network [1,2]. You can fire boot a VM on of top of a
auto-provisioned network topology and off you go. To get external access
you're only left with a floating IP association, but that's only one API
call away.

Cheers,
Armando

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
[2]
http://docs.openstack.org/newton/networking-guide/config-auto-allocation.html


>
> -Josh
>
> __
> OpenStack Development Mailing 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] Confusion around the complexity

[Joshua Harlow]

So I don't want to start to much of a flame-war and am really just 
trying to understand things that may be beyond me (so treat me nicely, ha).


The basic question that I've been wondering revolves around the 
following kind of 'thought experiment' that asks something along the 
lines of:


"""
If I am a user of openstack, say I'm an iphone developer, trying to get 
my 'game' and associated 'game APIs' setup in a manner that is HA (say 
fronted by a load-balancer), using my custom image, secure and visible 
to either an intranet or to the large internet then what is the steps I 
would have to do when interacting with openstack to accomplish this and 
what would the provider of openstack have to give to me as endpoints to 
make this possible.

"""

One of the obvious ones is nova and glance, and the API and usage there 
feels pretty straightforward as is (isn't really relevant to this 
conversation anyway). The one that feels bulky and confusing (at least 
for me) is the things I'd have to do in neutron to create and/or select 
networks, create and/or select subnets, create and/or select ports and 
so-on...


As a supposed iphone developer (dev/ops, yadayada) just trying to get 
his/her game to market why would I really want to know about selecting 
networks, create and/or selecting subnets, create and/or selecting ports 
and so-on...


It may just be how it is, but I'd like to at least ask if others are 
really happy with the interactions/steps (I guess we could/maybe we 
should ask similar questions around various other projects as well?); if 
I'm just an outlier that's ok, at least I asked :-P


-Josh

__
OpenStack Development Mailing 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][oslo.config][keystone] NoSuchOptError: no such option project_domain_name in group [keystone_authtoken]

[Eric K]

On a freshly stacked devstack (Jan 12), attempting to access
`cfg.CONF.keystone_authtoken.project_domain_name` gave the error:
NoSuchOptError: no such option project_domain_name in group
[keystone_authtoken]

I¹m a little confused because it¹s part of the [keystone_authtoken] config
section generated by devstack. Could anyone point me to where these options
are declared (I¹ve searched several repos) and maybe why this option doesn¹t
exist? Thanks a lot!

Of all the options supplied by devstack under [keystone_authtoken], the
following were accessible:
memcached_servers
signing_dir
cafile
auth_uri
auth_url
auth_type

But the following were unaccessible:
project_domain_name
project_name
user_domain_name
password
username



__
OpenStack Development Mailing 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] Consistent Versioned Endpoints

[Dean Troyer]

On Thu, Jan 12, 2017 at 12:35 PM, Scott D'Angelo
 wrote:
> Can we get to this "perfect world"? Let's discuss at the PTG.
> It is my understanding that we do not have the ability to schedule a time or
> room for such a cross-project discussion. Please chime in if interested,
> and/or make your interest known to scottda, mordred, or edleafe.

IIRC there may be some cross-project rooms available, but I can also
offer time/space in the OpenStackClient room for this discussion if
needed.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers

[Cathy Zhang]

This clash check was added on purpose to avoid the ambiguity of the following 
scenario (This is just one of many similar scenarios):

VM2, VM3 hosted on Int-Bridge1 of Server1
VM4 hosted on Int-Bridge2 of Server2
VM5 hosted on Int-Bridge3 of Server3

Chain1: VM1, VM2, VM4
Chain2: VM1, VM3, VM5

Suppose FC1 for Chain1 and FC2 for Chain2 are the same except logical source 
port(Igor's testing scenario). 
If we allow this, then when the Int-Bridge1 on Server1 receives the packet from 
VM2 or VM3, it can not distinguish 
which chain the packet is associated with and thus don't know whether to 
forward the packet to VM4 or VM5  
since the packet's n-tuple classification is the same (logical source port is 
not carried in the packet). 

If the SF2 on VM2 and the SF3 on VM3 are chain-ID aware (eg. Supports NSH), 
then the ambiguity can be resolved and we can remove this check. 
Another alternative is to support a chain-ID-correlation mechanism between the 
SF and the vSwitch. 

Thanks,
Cathy

 

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Thursday, January 12, 2017 7:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow 
classifiers

On 10 January 2017 at 14:13, Duarte Cardoso, Igor 
 wrote:
> Hi networking-sfc,
>
>
>
> While working on the SFC Graphs patch, I observed the following 
> limitation when creating port-chains: http://paste.openstack.org/show/594387/.
>
>
>
> My objective was to have 2 port-chains acting on the same 
> classification of traffic but from different logical source ports – my 
> expectation was that there wouldn’t be any clash here.
>
>
>
> However, the flow-classifiers clash when they are associated to those 
> 2 different port-chains.
>
>
>
> The exception is raised in [1] and the attributes of the 
> flow-classifier being checked are in [2], where neither logical source 
> port or logical destination port are specified.
>
>
>
> Is there a specific reasoning behind this or can it be considered a 
> bug? For the SFC Graphs work, it’s important that this limitation be 
> lifted – I’m happy to submit a patch to correct it.
>
> Let me know your thoughts.
>
>
>
> [1]
> https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192
> a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
>
> [2]
> https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f
> 408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

This must be the theme for this week's networking-sfc topic then, I ended up 
hitting the same problem while anylyzing the tempest race condition failures 
[1].

Each test creates a new port to use for its port pair, and a new flow 
classifier. The flow classifier has the same parameters, except for the source 
logical port (the related port is used here).
Apparently the test failure (a PortChainFlowClassifierInConflict
exception) is caused by a flow classifier from a previous test conflicting with 
the new one.

My thoughts here: this should indeed be allowed, and I think this restriction 
comes from an incorrect use of the *_conflict() functions
[2]: we should use the full flowclassifier_conflict() instead of 
flowclassifier_basic_conflict(), as it adds logical port conflict check and is 
the "main" conflict check function.
That is in fact the fix I just sent for review [3], local tempest runs went 
fine here. Feedback welcome!


[1] https://bugs.launchpad.net/networking-sfc/+bug/1655618
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191
[3] https://review.openstack.org/#/c/419525/

--
Bernard Cafarelli

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

Re: [openstack-dev] [infra][diskimage-builder] containers, Containers, CONTAINERS!

[Andre Florath]

Hello!

> The end result of this would be we have distro-minimal which depends on
> kernel, minimal-userspace, and yum/debootstrap to build a vm/baremetal
> capable image. We could also create a distro-container element which
> only depends on minimal-userspace and yum/debootstrap and creates a
> minimal container. The point being - the top level -container or
> -minimal elements are basically convenience elements for exporting a few
> vars and pulling in the proper elements at this point and the
> elements/code are broken down by the functionality they provide rather
> than use case.

This sounds awesome! Do we have some outline (etherpad) around
where we collect all those ideas?

Kind regards

Andre


__
OpenStack Development Mailing 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][tempest][api] community images, tempest tests, and API stability

[Brian Rosmaita]

Ken,

Thanks for the quick response ... we'll follow the procedure outlined in
the tempest HACKING.rst that you pointed out.

cheers,
brian

On 1/12/17 2:32 PM, Ken'ichi Ohmichi wrote:
> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
>> On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
>>
>>> But from meeting logs, it looks like impression was(if am not wrong) that
>>> Tempest test[1] is not doing the right thing and should be ok to change.
>>> I do not think this is the case, Tempest test is doing what API
>>> tells/behave. Below is what test does:
>>>  1. Tenant A creates image with explicitly visibility as private.
>>>  2. Tenant A add Tenant B as member of created image to allow Tenant B to
>>> use that.
>>>
>>> API [2] or Image sharing workflow [3] does not say/recommend anywhere that
>>> Image should not be created with private visibility as explicitly.
>>>
>>> For me this change breaks people "Creating Image with private visibility as
>>> *explicitly* and adding member to that" which will be 409 after glance
>>> proposal.
>>>
>>>
>>> Also changing tempest tests does not solve the problem, backward
>>> incompatible is still will be introduced in API.
>>
>> The issue is that we are proposing to introduce an incompatible change
>> in order to address an incoherence with image visibility semantics.  We
>> have acknowledged that this is a breaking change, but the impact of the
>> change is mitigated by the way that the default visibility value is
>> assigned in Ocata.
>>
>> As I've documented earlier in the thread, we have discussed this change
>> with the wider community and the API Working Group, and they are OK with it.
>>
>> The current tempest test has done its duty and identified an
>> incompatibility in the Ocata code.  We acknowledge that and salute you.
>> On balance, however, this change will be better for users (and as I've
>> documented earlier in the thread, we've minimized the impact of the
>> change), and we want to make it anyway.
> 
> It is difficult to expect the impact of API change is small by us as 
> developers.
> For example, if there could be some APPs which list images of both
> private and shared by depending on
> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
> broken after fixing it.
> Nova team faced such situation we expected the impact of the change
> was small but horizon was broken, then we reverted the change in the
> same dev cycle.
> Then Nova has now API microversions mechanism to avoid impacting to
> the existing APPs.
> 
> This is on very difficult balance, and we don't want to block the
> glance team development.
> We have some procedure for this situation like
> https://github.com/openstack/tempest/blob/master/HACKING.rst#2-bug-fix-on-core-project-needing-tempest-changes
> I did put some comments on https://review.openstack.org/#/c/414261 .
> Could you check that?
> 
> Thanks
> Ken Ohmichi
> 
> ---
> 
>> So the situation isn't that we are claiming that your current code is
>> flawed.  Rather, it is that we are asking the QA team to approve a
>> change to that test in order to address a change we are making in Ocata,
>> a change that has the support of the OpenStack community.
>>
>> thanks,
>> brian
>>
>>>
>>> .. 1
>>> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338
>>>
>>> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
>>> .. 3
>>> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
>>>
>>>
>>> Regards
>>> Ghanshyam Mann
>>> +818011120698
>>>
>>>
>>> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
>>> wrote:
>>>
 On 1/5/17 10:19 AM, Brian Rosmaita wrote:
> To anyone interested in this discussion: I put it on the agenda for
> today's API-WG meeting (16:00 UTC):
>
> https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda

 As you probably noticed in the API-WG newsletter [A], this issue was
 discussed at last week's API-WG meeting.  The complete discussion is in
 the meeting log [B], but the tldr; is that the proposed change is
 acceptable.  I'll address specific points inline for those who are
 interested, but the key request from the Glance team right now is that
 the QA team approve this patch:

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


 [A]
 http://lists.openstack.org/pipermail/openstack-dev/2017-
 January/109698.html
 [B]
 http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
 wg.2017-01-05-16.00.log.html

> On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
>> Thanks Brian for bringing this up, same we been discussing last week on
 QA
>> channel and this patch[1] but I completely agree with Matthew opinion
 here.
>> There is no doubt that this change(4-valued) are much better and clear
 than
>> old one. This makes much defined and clear way of defining the image
>> 

Re: [openstack-dev] [ironic] Stepping down as PTL after this cycle

[Loo, Ruby]

Jim,

(Now that the shock has worn off). Thanks for being such a great PTL. I very 
much appreciated what you did/do as PTL! And welcome back to the land of 
coding, etc. :)

--ruby

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

Date: Friday, January 6, 2017 at 2:02 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [ironic] Stepping down as PTL after this cycle

Hi friends,
I'll be stepping down as PTL after Ocata is done. I'll still be 100% dedicated 
to the project, but I'd like to be able to focus more on writing code and 
reinforcing the bridges between us and other projects (Nova, Neutron, etc).
I'd love to see two or more people step up and run next cycle in a real 
election. I'm happy to chat with anyone interested in becoming the Pike PTL, if 
you have questions or need a candidacy review or whatever.
It's been an amazing experience leading this project. You're all awesome, and 
I'm grateful you chose me to do so. I hope the following cycles are even 
better. :)

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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Yolanda Robla Mota]

>From my point of view, i've been using that either on infra with
puppet-infracloud, glean.. and now with TripleO. So in my opinion, it shall
be an independent project, with core contributors from both sides.

On Thu, Jan 12, 2017 at 8:51 PM, Paul Belanger 
wrote:

> On Thu, Jan 12, 2017 at 02:11:42PM -0500, James Slagle wrote:
> > On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi 
> wrote:
> > > On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger 
> wrote:
> > >> Greetings,
> > >>
> > >> With the containerization[1] of tripleo, I'd like to know more about
> the future of
> > >> diskimage-builder as it relates to the tripleo project.
> > >>
> > >> Reading the recently approved spec for containers, container (image)
> builds are
> > >> no longer under the control of tripleo; by kolla. Where does this
> leave
> > >> diskimage-builder as a project under tripleo?  I specifically ask,
> because I'm
> > >> wanting to start down the path of using diskimage-builder as an
> interface to
> > >> containers.
> > >>
> > >> Basically, is it time to move diskimage-builder out from the tripleo
> project
> > >> into another, or its own? Or is tripleo wanting to more forward on
> development
> > >> efforts on diskimage-builder.
> > >
> > > Looking at stats on who is actively contributing into DIB:
> > > http://stackalytics.com/?module=diskimage-builder
> > >
> > > It seems that we have some folks from infra and some folks on dib
> > > only, and a few contributors from TripleO.
> > >
> > > I guess the best option is to ask DIB contributors: do you want to own
> > > the project you're committing to?
> > > If not, is it something that should stay in TripleO (imo no) or move
> > > into openstack-infra (imo yes, if infra agrees).
> > >
> > > With my PTL hat, I'm really open to this thing and I wouldn't mind to
> > > transfer ownership to another group.
> >
> > I was under the impression it was already it's own project team based on:
> > http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html
> >
> > It looks like the change was never made in governance however.
> >
> Yes, it just looks like Greg created new core reviewers, not officially
> breaking
> away from tripleo.
>
> If everybody is on board with moving diskimage-builder outside of tripleo,
> we
> need to decided where it lives. Two options come to mind:
>
> 1) Move diskimage-builder into own (big tent?) project. Setup a new PTL,
> etc.
> 2) Move diskimage-builder into openstack-infra (fungi PTL).
> 3) Keep diskimage-builder under tripleo (EmilienM PTL).
>
> Thoughts?
>
> > The reason I -1'd Paul's TripleO spec and suggested it be proposed to
> > diskimage-builder was due to:
> > http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html
> and
> > https://review.openstack.org/#/c/336109/
> >
> > I just want to make sure the right set of reviewers who are driving
> > dib development see the spec proposal.
> >
> > --
> > -- 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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Yolanda Robla Mota
NFV Partner Engineer
yrobl...@redhat.com
+34 605641639
__
OpenStack Development Mailing 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] subscribe to the OpenStack release calendar

[Lance Bragstad]

This is awesome! I pretty much just 'Select All' deleted my other calendars
I use for tracking this kind of information.

Thank you, Doug!

On Thu, Jan 12, 2017 at 12:41 PM, Emilien Macchi  wrote:

> On Wed, Jan 11, 2017 at 1:51 PM, Doug Hellmann 
> wrote:
> > Excerpts from Doug Hellmann's message of 2017-01-06 15:19:35 -0500:
> >>
> >> > On Jan 6, 2017, at 1:14 PM, Julien Danjou  wrote:
> >> >
> >> > On Fri, Jan 06 2017, Doug Hellmann wrote:
> >> >
> >> > Hi Doug,
> >> >
> >> >> The link for the Ocata schedule is
> >> >> https://releases.openstack.org/ocata/schedule.ics
> >> >>
> >> >> We will have a similar Pike calendar available as soon as the
> >> >> schedule is finalized.
> >> >
> >> > Thank you, this is great. One question: could it be possible to have
> >> > only one ICS for all releases? Maybe having one per release plus a
> >> > "all.ics"?
> >> >
> >> > I'm lazy I don't want to track and add each calendar every 6 months.
> :-)
> >> >
> >> > --
> >> > Julien Danjou
> >> > ;; Free Software hacker
> >> > ;; https://julien.danjou.info
> >>
> >> See https://review.openstack.org/417495
> >
> > This patch has merged, and the new calendar is available at
> > https://releases.openstack.org/schedule.ics
>
> This is really awesome.
> I found useful to document it in the PTL guide:
> https://review.openstack.org/419600
>
> Any feedback is welcome.
>
> > Doug
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> 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 Development Mailing 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] Mapping Launchpad to Storyboard

[Kendall Nelson]

Hello All!

   The storyboard team has created another blog post to help you learn how
some of the more utilized capabilities of launchpad work in Storyboard so
please take a look! [1]

And if you missed our previous post discussing why we want to move to
Storyboard please take a look at that too [2] :)

Lastly, if you want to play around with it [3], read the documentation [4],
attend our weekly meetings with feedback [5], or check out the real thing
[6] please feel free to do so.

Thanks!

Kendall Nelson (diablo_rojo) and the Storyboard Team

[1] https://storyboard-blog.io/mapping-launchpad-to-storyboard.html
[2] https://storyboard-blog.io/why-storyboard-for-openstack.html
[3] https://storyboard-dev.openstack.org/
[4] http://docs.openstack.org/infra/storyboard/
[5]  https://wiki.openstack.org/wiki/StoryBoard
[6] https://storyboard.openstack.org/
__
OpenStack Development Mailing 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][diskimage-builder] Status of diskimage-builder

[Paul Belanger]

On Thu, Jan 12, 2017 at 02:11:42PM -0500, James Slagle wrote:
> On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi  wrote:
> > On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger  
> > wrote:
> >> Greetings,
> >>
> >> With the containerization[1] of tripleo, I'd like to know more about the 
> >> future of
> >> diskimage-builder as it relates to the tripleo project.
> >>
> >> Reading the recently approved spec for containers, container (image) 
> >> builds are
> >> no longer under the control of tripleo; by kolla. Where does this leave
> >> diskimage-builder as a project under tripleo?  I specifically ask, because 
> >> I'm
> >> wanting to start down the path of using diskimage-builder as an interface 
> >> to
> >> containers.
> >>
> >> Basically, is it time to move diskimage-builder out from the tripleo 
> >> project
> >> into another, or its own? Or is tripleo wanting to more forward on 
> >> development
> >> efforts on diskimage-builder.
> >
> > Looking at stats on who is actively contributing into DIB:
> > http://stackalytics.com/?module=diskimage-builder
> >
> > It seems that we have some folks from infra and some folks on dib
> > only, and a few contributors from TripleO.
> >
> > I guess the best option is to ask DIB contributors: do you want to own
> > the project you're committing to?
> > If not, is it something that should stay in TripleO (imo no) or move
> > into openstack-infra (imo yes, if infra agrees).
> >
> > With my PTL hat, I'm really open to this thing and I wouldn't mind to
> > transfer ownership to another group.
> 
> I was under the impression it was already it's own project team based on:
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html
> 
> It looks like the change was never made in governance however.
> 
Yes, it just looks like Greg created new core reviewers, not officially breaking
away from tripleo.

If everybody is on board with moving diskimage-builder outside of tripleo, we
need to decided where it lives. Two options come to mind:

1) Move diskimage-builder into own (big tent?) project. Setup a new PTL, etc.
2) Move diskimage-builder into openstack-infra (fungi PTL).
3) Keep diskimage-builder under tripleo (EmilienM PTL).

Thoughts?

> The reason I -1'd Paul's TripleO spec and suggested it be proposed to
> diskimage-builder was due to:
> http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html and
> https://review.openstack.org/#/c/336109/
> 
> I just want to make sure the right set of reviewers who are driving
> dib development see the spec proposal.
> 
> -- 
> -- 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

__
OpenStack Development Mailing 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] Unit tests for a review

[Ajay Kalambur (akalambu)]

Hi
I am looking into writing unit tests for a review
https://review.openstack.org/#/c/387687/

Basically it modifies the deallocate for instance function to only deallocate 
ports to which this instance is bound to

So this is more like a scenario test where the port is unbound outside of nova.

So what would be the closest test to start with and modify to get this scenario 
going.

Would this be better of as a functional test vs a unit test?

Ajay


__
OpenStack Development Mailing 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][tempest][api] community images, tempest tests, and API stability

[Ken'ichi Ohmichi]

2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
> On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
>
>> But from meeting logs, it looks like impression was(if am not wrong) that
>> Tempest test[1] is not doing the right thing and should be ok to change.
>> I do not think this is the case, Tempest test is doing what API
>> tells/behave. Below is what test does:
>>  1. Tenant A creates image with explicitly visibility as private.
>>  2. Tenant A add Tenant B as member of created image to allow Tenant B to
>> use that.
>>
>> API [2] or Image sharing workflow [3] does not say/recommend anywhere that
>> Image should not be created with private visibility as explicitly.
>>
>> For me this change breaks people "Creating Image with private visibility as
>> *explicitly* and adding member to that" which will be 409 after glance
>> proposal.
>>
>>
>> Also changing tempest tests does not solve the problem, backward
>> incompatible is still will be introduced in API.
>
> The issue is that we are proposing to introduce an incompatible change
> in order to address an incoherence with image visibility semantics.  We
> have acknowledged that this is a breaking change, but the impact of the
> change is mitigated by the way that the default visibility value is
> assigned in Ocata.
>
> As I've documented earlier in the thread, we have discussed this change
> with the wider community and the API Working Group, and they are OK with it.
>
> The current tempest test has done its duty and identified an
> incompatibility in the Ocata code.  We acknowledge that and salute you.
> On balance, however, this change will be better for users (and as I've
> documented earlier in the thread, we've minimized the impact of the
> change), and we want to make it anyway.

It is difficult to expect the impact of API change is small by us as developers.
For example, if there could be some APPs which list images of both
private and shared by depending on
https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
broken after fixing it.
Nova team faced such situation we expected the impact of the change
was small but horizon was broken, then we reverted the change in the
same dev cycle.
Then Nova has now API microversions mechanism to avoid impacting to
the existing APPs.

This is on very difficult balance, and we don't want to block the
glance team development.
We have some procedure for this situation like
https://github.com/openstack/tempest/blob/master/HACKING.rst#2-bug-fix-on-core-project-needing-tempest-changes
I did put some comments on https://review.openstack.org/#/c/414261 .
Could you check that?

Thanks
Ken Ohmichi

---

> So the situation isn't that we are claiming that your current code is
> flawed.  Rather, it is that we are asking the QA team to approve a
> change to that test in order to address a change we are making in Ocata,
> a change that has the support of the OpenStack community.
>
> thanks,
> brian
>
>>
>> .. 1
>> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338
>>
>> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
>> .. 3
>> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
>>
>>
>> Regards
>> Ghanshyam Mann
>> +818011120698
>>
>>
>> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
>> wrote:
>>
>>> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
 To anyone interested in this discussion: I put it on the agenda for
 today's API-WG meeting (16:00 UTC):

 https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
>>>
>>> As you probably noticed in the API-WG newsletter [A], this issue was
>>> discussed at last week's API-WG meeting.  The complete discussion is in
>>> the meeting log [B], but the tldr; is that the proposed change is
>>> acceptable.  I'll address specific points inline for those who are
>>> interested, but the key request from the Glance team right now is that
>>> the QA team approve this patch:
>>>
>>> https://review.openstack.org/#/c/414261/
>>>
>>>
>>> [A]
>>> http://lists.openstack.org/pipermail/openstack-dev/2017-
>>> January/109698.html
>>> [B]
>>> http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
>>> wg.2017-01-05-16.00.log.html
>>>
 On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
> Thanks Brian for bringing this up, same we been discussing last week on
>>> QA
> channel and this patch[1] but I completely agree with Matthew opinion
>>> here.
> There is no doubt that this change(4-valued) are much better and clear
>>> than
> old one. This makes much defined and clear way of defining the image
> visibility by/for operator/user.
>>>
>>> Yes, we think that the change clarifies the visibility semantics of
>>> images and, in particular, fixes the problem of there being "private"
>>> images that aren't actually private.
>>>
>>> The current situation is easily misunderstood by end users, as evidenced
>>> by bugs that have been 

Re: [openstack-dev] [qa] glance issue at QA team meeting on 12 January

[Brian Rosmaita]

Hello Ken'ichi and the QA Team,

Sorry about the confusion over today's meeting time.  All I was going to
say at the meeting was it would be great if some core reviewers could
take a look at the glance tempest patch,
https://review.openstack.org/#/c/414261/.

I realize that you give each patch all the care and attention it
deserves, but this is an important patch for Glance, so we'd appreciate
anything you can do to expedite it.  We discussed the issue again at
today's API-WG meeting, and agreed that what's needed is an "official"
response from the QA team concerning the acceptability of the patch so
that we can figure out our next steps.

thanks,
brian


On 1/11/17 12:10 PM, Brian Rosmaita wrote:
> Hello QA Team,
> 
> There wasn't an agenda for 12 January on the Meetings/QATeamMeeting page
> on the wiki, so I took the liberty of creating one.  I added an item
> under the "Tempest" section to discuss a patch to modify a Glance test
> that is currently blocking a few Glance Ocata priorities (community
> images and rolling upgrades).
> 
> I put the following link on the agenda to provide some background about
> the issue and the subsequent discussion:
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/109817.html
> 
> So far a few QA team members have weighed in on the discussion, either
> on the ML or on the patch, but I need to get an official decision from
> the QA team on whether the patch is acceptable or not so that we can get
> moving.  As you know, O-3 is fast approaching!
> 
> https://review.openstack.org/#/c/414261/
> 
> thanks,
> brian
> 


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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[James Slagle]

On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi  wrote:
> On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger  wrote:
>> Greetings,
>>
>> With the containerization[1] of tripleo, I'd like to know more about the 
>> future of
>> diskimage-builder as it relates to the tripleo project.
>>
>> Reading the recently approved spec for containers, container (image) builds 
>> are
>> no longer under the control of tripleo; by kolla. Where does this leave
>> diskimage-builder as a project under tripleo?  I specifically ask, because 
>> I'm
>> wanting to start down the path of using diskimage-builder as an interface to
>> containers.
>>
>> Basically, is it time to move diskimage-builder out from the tripleo project
>> into another, or its own? Or is tripleo wanting to more forward on 
>> development
>> efforts on diskimage-builder.
>
> Looking at stats on who is actively contributing into DIB:
> http://stackalytics.com/?module=diskimage-builder
>
> It seems that we have some folks from infra and some folks on dib
> only, and a few contributors from TripleO.
>
> I guess the best option is to ask DIB contributors: do you want to own
> the project you're committing to?
> If not, is it something that should stay in TripleO (imo no) or move
> into openstack-infra (imo yes, if infra agrees).
>
> With my PTL hat, I'm really open to this thing and I wouldn't mind to
> transfer ownership to another group.

I was under the impression it was already it's own project team based on:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html

It looks like the change was never made in governance however.

The reason I -1'd Paul's TripleO spec and suggested it be proposed to
diskimage-builder was due to:
http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html and
https://review.openstack.org/#/c/336109/

I just want to make sure the right set of reviewers who are driving
dib development see the spec proposal.

-- 
-- James Slagle
--

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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Emilien Macchi]

On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger  wrote:
> Greetings,
>
> With the containerization[1] of tripleo, I'd like to know more about the 
> future of
> diskimage-builder as it relates to the tripleo project.
>
> Reading the recently approved spec for containers, container (image) builds 
> are
> no longer under the control of tripleo; by kolla. Where does this leave
> diskimage-builder as a project under tripleo?  I specifically ask, because I'm
> wanting to start down the path of using diskimage-builder as an interface to
> containers.
>
> Basically, is it time to move diskimage-builder out from the tripleo project
> into another, or its own? Or is tripleo wanting to more forward on development
> efforts on diskimage-builder.

Looking at stats on who is actively contributing into DIB:
http://stackalytics.com/?module=diskimage-builder

It seems that we have some folks from infra and some folks on dib
only, and a few contributors from TripleO.

I guess the best option is to ask DIB contributors: do you want to own
the project you're committing to?
If not, is it something that should stay in TripleO (imo no) or move
into openstack-infra (imo yes, if infra agrees).

With my PTL hat, I'm really open to this thing and I wouldn't mind to
transfer ownership to another group.

Thanks,

> [1] 
> https://specs.openstack.org/openstack/tripleo-specs/specs/ocata/containerize-tripleo-overcloud.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



-- 
Emilien Macchi

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

Re: [openstack-dev] [nova][keystone][cinder] Quota Implementation

[Sajeesh Cimson Sasi]

Dear All,
  Quota as service or library .IMHO we have to fix one of the 
methods, so that we can go ahead with the implementation.
best regards,
  sajeesh

From: Sajeesh Cimson Sasi [sajeesh...@cern.ch]
Sent: 14 December 2016 23:17:08
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resourcesand 
limits in the Keystone

Hi,
I also feel that quota as a service is the best approach.It is justified as 
well, since we have multiple projects(Nova,Cinder,Neutron) now ,having the 
concept of quotas.Keeping it under a single umbrella, paves the way for lesser 
code duplication and easier feature enhancement like adoption of hierarchical 
quotas, and also better code management.
best regards,
 sajeesh


From: Andrey Volkov [avol...@mirantis.com]
Sent: 14 December 2016 17:00:32
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and
limits in the Keystone

Hi,

I think one of the issues we're trying to solve here is duplication
reducing. Quotas in OpenStack commonly contain two parts: limits
management and limits enforcement.

If we're talking about library (delimiter) vs service (keystone or quota
service) for a duplication reducing in a limits management then IMO service is
more appropriate way because:

- Now we have API endpoint for limits
  management for the end user and we will need it in the future. Library can
  reduce an amount of code for such endpoint but can't totally eliminate it.
- Besides the code in services, we have api-ref, docs, and clients also
  and library can't reduce an effort for supporting those.
- Centralized limits management service can provide fresh and
  consistent API (see quota_class, quota_sets).

If we're talking about limits enforcement then it's more subtle thing.
I really agree with Jay that problem can be related to the cache for
usages. And I don't see the way how we can skip saving into reservation
table because we can easily define a moment of reservation with
reservation table but it can be hard with "real" objects like instance
as they have its own logic of creating.

I think a library can be appropriate if services like nova or cinder
have a possibility to deeply integrate external libraries (like django
apps). I mean if a library has own DB tables, cli commands, etc. it
can be seamlessly integrated to the main app. I'm not sure it's the
case for nova, for example. Therefore, for me, separate service
is the winner here too.

Sajeesh Cimson Sasi writes:

> Hi,
> There was an ongoing project of delimiter for Cross Project Quota 
> Management.
> But I don't know the current status.
> Kindly have a look at it.
> https://review.openstack.org/#/c/284454/
> More discussions are required on this.As more and more  projects or 
> services are having the concept ofquotas,Quota as a service can also be 
> thought of.Anyway more discussions are required on this topic.
>best regards,
> sajeesh
> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: 13 December 2016 18:55:14
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and 
> limits in the Keystone
>
> On 12/13/2016 08:09 AM, Kseniya Tychkova wrote:
>> Hi,
>> I would like to share a spec [1] with you.
>> The main idea of this spec is to start a discussion about quota
>> management in the OpenStack.
>>
>> Quotas are scattered across OpenStack services. Each service defines
>> it's own model and API for
>> managing resource's limits. Because of that, there are several problems:
>>
>>   * Names of the resources and resource-service mapping  are hardcoded.
>> They are hardcoded in the service code (Nova, for example) and it
>> should be hardcoded in the client code (Horizon, for example).
>>
>>   * There is no centralized quota management for OpenStack projects.
>>   * Cinder, Nova and Neutron support (or going to support) hierarchical
>> quotas in different ways.
>>
>> There should be a single point of managing quotas in OpenStack.
>> Keystone looks like a proper place to store resource's limits because:
>>
>>   * Keystone stores projects
>>   * Limits are belong to project.
>
> Another excellent reason to store quota limits in Keystone is because
> virtually all non-list operations require some interaction with quota
> limits, and requiring Nova (or Cinder or Neutron) to call out to yet
> another service each time the user makes one of those non-list
> operations is sub-optimal when Nova is already making a call to Keystone
> for authentication.
>
> The alternative is to have a separate REST API service just for storing
> and returning the quota limits and have Nova, 

Re: [openstack-dev] [release] subscribe to the OpenStack release calendar

[Emilien Macchi]

On Wed, Jan 11, 2017 at 1:51 PM, Doug Hellmann  wrote:
> Excerpts from Doug Hellmann's message of 2017-01-06 15:19:35 -0500:
>>
>> > On Jan 6, 2017, at 1:14 PM, Julien Danjou  wrote:
>> >
>> > On Fri, Jan 06 2017, Doug Hellmann wrote:
>> >
>> > Hi Doug,
>> >
>> >> The link for the Ocata schedule is
>> >> https://releases.openstack.org/ocata/schedule.ics
>> >>
>> >> We will have a similar Pike calendar available as soon as the
>> >> schedule is finalized.
>> >
>> > Thank you, this is great. One question: could it be possible to have
>> > only one ICS for all releases? Maybe having one per release plus a
>> > "all.ics"?
>> >
>> > I'm lazy I don't want to track and add each calendar every 6 months. :-)
>> >
>> > --
>> > Julien Danjou
>> > ;; Free Software hacker
>> > ;; https://julien.danjou.info
>>
>> See https://review.openstack.org/417495
>
> This patch has merged, and the new calendar is available at
> https://releases.openstack.org/schedule.ics

This is really awesome.
I found useful to document it in the PTL guide:
https://review.openstack.org/419600

Any feedback is welcome.

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



-- 
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] Consistent Versioned Endpoints

[Scott D'Angelo]

TL;DR: Let's discuss Version Discovery and Endpoints in the Service Catalog
at the PTG in Atlanta.

The topic of Versioning and the Endpoints discovered in the Service Catalog
was discussed in today's API Working Group Meeting[1].
A previous ML post[2] claimed:

In a perfect world, every endpoint would return the same type of resource -
most likely the versions resource as described in the API WG Microversions
spec. It would also be nice if version negotiation can happen without
requiring authentication, the easiest path to which would be supporting the
'max_version' and 'min_version' fields in the root versions resource.

One problem is multiple versioned service names in the catalog for a given
service[3], as opposed to a single endpoint that would return version
info[4].

Can we get to this "perfect world"? Let's discuss at the PTG.
It is my understanding that we do not have the ability to schedule a time
or room for such a cross-project discussion. Please chime in if interested,
and/or make your interest known to scottda, mordred, or edleafe.

Scott D'Angelo
scott.dang...@ibm.com

[1]
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-12-16.00.log.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-August/102549.html
[3] http://paste.openstack.org/show/594751/
[4] http://paste.openstack.org/show/594754/
__
OpenStack Development Mailing 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] [release] Release countdown for week R-5, Jan 16-20

[Doug Hellmann]

Focus
-

Feature work and major refactoring should be starting to wrap up
as we approach the third milestone and various feature and release
freeze dates.

The deadline for non-client library releases is Thursday 19 Jan.
We do not grant Feature Freeze Extensions for any libraries, so
that is a hard freeze date. Any feature work that requires updates
to non-client libraries should be prioritized so it can be completed
by that time.

Release Tasks
-

As we did at the end of Newton, when the time comes to create
stable/ocata branches they will be configured so that members of
the $project-release group in gerrit have permission to approve
patches.  This group should be a small subset of the core review
team, aware of the priorities and criteria for patches to be approved
as we work toward release candidates. Release liaisons should ensure
that these groups exist in gerrit and that their membership is
correct for this cycle.  Please coordinate with the release management
team if you have any questions.

General Notes
-

We will start the soft string freeze during R-4 (23-27 Jan). See
https://releases.openstack.org/ocata/schedule.html#o-soft-sf for
details

The release team is now publishing the release calendar using ICS.
Subscribe your favorite calendaring software to
https://releases.openstack.org/schedule.ics for automatic updates.

Important Dates
---

Final release of non-client libraries: 19 Jan

Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan

Ocata release schedule: http://releases.openstack.org/ocata/schedule.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] [nova] placement/resource providers update 7

[Jay Pipes]

On 01/09/2017 05:29 AM, Chris Dent wrote:

On Fri, 6 Jan 2017, Chris Dent wrote:


* CORS support in placement API:
 https://review.openstack.org/#/c/392891/


This is one we should probably get in in Ocata because it enables
the sole piece of configurability that is present in the WSGI
middleware stack used for the placement API. Unlike nova-api, no
paste.ini file is used. In order to add CORS to the placement API,
this change is required. It will check for cors config in the
*.conf file, and if present, include the middleware.

One can image some rather nice javascript-driver single page
applications (or otherwise) that read the placement API to provide
overviews of resource data. Such things are made a lot easier by
having CORS in the picture.


Yeah, agreed. And it's really not a huge patch or anything.

-jay

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

[openstack-dev] [neutron] Neutron Pike PTG

[Armando M.]

Hi neutrinos,

The time for the PTG is approaching and if you are wondering about topics
and various agenda arrangements, you should consider the PTG more like a
mid-cycle on steroids: each project will be working on its own agenda,
usually via etherpads, and publish updates over the ML, up until and during
the week of the PTG.

Therefore, do not expect any published agenda, beyond a daily map of where
teams will be gathering in which rooms. We also need to work out on how to
arrange cross-projects conversations. Please expect to learn more from the
team organizers.

For now, please start collecting ideas on [2]. Once we got critical mass on
[2], I'll work with the drivers team to finalize and sanitize a more formal
agenda, which will then be published on a new etherpad (TBD). For those who
cannot participate in person to the event, we will provide a mid-cycle
report.

Cheers,
Armando

[1] https://www.openstack.org/ptg/
[2] https://etherpad.openstack.org/p/neutron-ptg-pike
__
OpenStack Development Mailing 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] Limitation on port chains + flow classifiers

[Duarte Cardoso, Igor]

Thanks Bernard, Louis, IRC meeting,

Given the encapsulation requirement when having SFC Graphs, there is then no 
need to call flowclassifier_basic_conflict() for the said graphs. I will see 
how to avoid calling flowclassifier_basic_conflict() specifically when creating 
graphs of port chains. Will likely need to touch multiple parts of the code 
since port chain resources must already exist before a graph can connect them. 

Best regards,
Igor.

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Thursday, January 12, 2017 3:44 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow 
classifiers

On 10 January 2017 at 14:13, Duarte Cardoso, Igor 
 wrote:
> Hi networking-sfc,
>
>
>
> While working on the SFC Graphs patch, I observed the following 
> limitation when creating port-chains: http://paste.openstack.org/show/594387/.
>
>
>
> My objective was to have 2 port-chains acting on the same 
> classification of traffic but from different logical source ports – my 
> expectation was that there wouldn’t be any clash here.
>
>
>
> However, the flow-classifiers clash when they are associated to those 
> 2 different port-chains.
>
>
>
> The exception is raised in [1] and the attributes of the 
> flow-classifier being checked are in [2], where neither logical source 
> port or logical destination port are specified.
>
>
>
> Is there a specific reasoning behind this or can it be considered a 
> bug? For the SFC Graphs work, it’s important that this limitation be 
> lifted – I’m happy to submit a patch to correct it.
>
> Let me know your thoughts.
>
>
>
> [1]
> https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192
> a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
>
> [2]
> https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f
> 408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

This must be the theme for this week's networking-sfc topic then, I ended up 
hitting the same problem while anylyzing the tempest race condition failures 
[1].

Each test creates a new port to use for its port pair, and a new flow 
classifier. The flow classifier has the same parameters, except for the source 
logical port (the related port is used here).
Apparently the test failure (a PortChainFlowClassifierInConflict
exception) is caused by a flow classifier from a previous test conflicting with 
the new one.

My thoughts here: this should indeed be allowed, and I think this restriction 
comes from an incorrect use of the *_conflict() functions
[2]: we should use the full flowclassifier_conflict() instead of 
flowclassifier_basic_conflict(), as it adds logical port conflict check and is 
the "main" conflict check function.
That is in fact the fix I just sent for review [3], local tempest runs went 
fine here. Feedback welcome!


[1] https://bugs.launchpad.net/networking-sfc/+bug/1655618
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191
[3] https://review.openstack.org/#/c/419525/

--
Bernard Cafarelli

__
OpenStack Development Mailing 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] [trove][ptg] Pike PTG Etherpad

[MCCASLAND, TREVOR]

trove now has an etherpad for listing its PTG topics:
https://etherpad.openstack.org/p/trove-pike-ptg-topics
You can find it listed on the PTG Pike Etherpads wiki:
https://wiki.openstack.org/wiki/PTG/Pike/Etherpads

Feel free to add topics, Thanks!
Trevor

__
OpenStack Development Mailing 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] New deadline for PTG Travel Support Program

[Pete Birley]

Thierry,

Thanks! As an independent contributor, it can be really hard to finance
these international trips, especially when there is no commercial element.
It is therefore really great, and appreciated, that you have extended this
program from the Summit to cover the PTG.

Cheers,

Pete

On Thu, Jan 12, 2017 at 4:51 PM, Thierry Carrez 
wrote:

> Hi everyone,
>
> The PTG Travel Support Program helps contributors that are not otherwise
> funded to join their team gathering at the Project Teams Gathering. See
> http://www.openstack.org/ptg#tab_travel for more explanations.
>
> The Travel Support Program applications were organized in two phases,
> and the second (and last) phase is closing very soon. It was originally
> set to close on January 15, but we'll accept applications until
> end-of-day Tuesday, January 17th. Apply now if you need it:
>
> https://openstackfoundation.formstack.com/forms/travelsupportptg_atlanta
>
> These submissions will be evaluated next week and grantees will be
> notified by Friday, January 20th.
>
> NB: People who did not get accepted during the first phase are
> automatically re-considered in phase 2, without needing to re-apply.
>
> This email is also the occasion to remind you to register for the event
> if you haven't yet!  Prices will increase on January 24 and February 14.
> Book now at:
>
> https://pikeptg.eventbrite.com/
>
> Finally, if you haven't booked your hotel yet, I encourage you to book
> ASAP in the event hotel itself using the PTG room block. It helps us
> keep the costs under control and helps you share the most time with the
> event participants. The hotel block closes on January 27. Book now using
> this link:
>
> https://www.starwoodmeeting.com/events/start.action?id=
> 1609140999=381BF4AA
>
> Thanks!
>
> --
> 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
>



-- 

[image: Port.direct] 

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Chris Dent]

Greetings OpenStack community,

Exciting meeting today, lots of people, lots of discussion[0]. We started out 
talking about the service-types-authority[4] and whether the api-wg should be 
more directly involved in it. Since there's a fair bit of overlap between 
participants in both groups, we decided that while it is very important for the 
api-wg to help ensure good use and form of the service catalog (and guidelines 
should be created stating as much) there was no particular need to do anything 
more than be present and aware. However this did lead to talk about wanting 
consistent unversioned endpoints in the service catalog. scottda was 
volunteered to follow up on getting some discussion about this happening at the 
PTG (with moral support from edleafe, mordred, and dtroyer).

We then talked about the ongoing issues with the visibility changes in glance. 
There's consensus that the changes (in glance and tempest) are necessary.

Finally we talked about some guidelines, notably ongoing interest in the 
capabilities review https://review.openstack.org/#/c/386555/ and what the 
api-wg's role should be in reviewing and discussing it. If you're curious about 
this it's probably easiest to have a look at the IRC log as there's no simple 
summary: 
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-12-16.00.log.html#l-202

Lots of other guidelines in progress and awaiting your feedback if you have 
time to give it (see below).

# Newly Published Guidelines

Nothing new

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None at the moment, but you are always very welcome to review stuff in the next 
section.

# Guidelines Currently Under Review [3]

* Add guidelines on usage of state vs. status
  https://review.openstack.org/#/c/411528/

* Add guidelines for boolean names
  https://review.openstack.org/#/c/411529/

* Clarify the status values in versions
  https://review.openstack.org/#/c/411849/

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

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

* Add guideline for invalid query parameters
  https://review.openstack.org/417441

# Highlighting your API impacting issues

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

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

Thanks for reading and see you next week!

# References

[0] 
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-12-16.00.html
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://github.com/openstack/service-types-authority

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

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

Re: [openstack-dev] [tripleo] CI Squad Meeting Summary

[Emilien Macchi]

On Thu, Jan 12, 2017 at 12:26 PM, Attila Darazs  wrote:
> We had our first meeting as the the CI Squad today. We re-purposed our
> "Quickstart to Upstream Transitioning" meeting into the Squad meeting, so
> the topics were and will be focused on the transition for the next month or
> so.
>
> Everybody interested in the TripleO CI and Quickstart is welcome to join the
> meeting:
>
> Time: Thursdays, 15:30-16:30 UTC
> Place: https://bluejeans.com/4113567798/
>
> Meeting summary:
>
> * The Quickstart transition does not seem to have any blockers or
> bottlenecks for the time being, we are on track to be ready at the end of
> the Ocata cycle, and switch in the beginning of Pike.
>
> * The new Quickstart based OVB jobs are working consistently and reliably,
> though the tinyrpc.server bug affected them just like the regular jobs.
>
> * Got our first overcloud deploy today on the Quickstart based nodepool
> multinode jobs, big kudos to bkero and trown for making it happen. The
> verification part still needs work though.
>
> * The experimental queue is overloaded, we will move OVB workloads to the
> multinode jobs once we get them working reliably.
>
> * We might want to change the experimental OVB jobs to run container and
> composable upgrade jobs instead for increased coverage, but we need more
> input on that, we will discuss it on the next TripleO meeting.
>
> * Selecting the proper configuration to use for each gate/period job is not
> optimal, we should rethink the system during the transition to Quickstart.
> This needs a design session. Also we need an up-to-date job type -
> functionality matrix like this[1].
>
> * We voted to keep the meetings on BlueJeans and at 15:30 UTC.
>
> * We will keep tracking the transition work on the RDO Infra Trello board
> with the [Q to U] tags, maybe move to the CI Squad board on Trello later. We
> should also look at Storyboard and see if that would be useful to switch to.
>
> Full meeting minutes and notes:
> https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

Excellent summary Attila and thanks for driving this work in the open.

It would be awesome to have one or multiple sessions about CI work in
TripleO at the next PTG.
Please let us know if that's something that would be possible
regarding the folks involved in CI going there.

Feel free to propose session(s) here:
https://etherpad.openstack.org/p/tripleo-ptg-pike

Thanks,

> Best regards,
> Attila
>
> [1] https://review.openstack.org/#/c/399269/7/README.md
>
> __
> OpenStack Development Mailing 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] [tripleo] CI Squad Meeting Summary

[Attila Darazs]

We had our first meeting as the the CI Squad today. We re-purposed our 
"Quickstart to Upstream Transitioning" meeting into the Squad meeting, 
so the topics were and will be focused on the transition for the next 
month or so.


Everybody interested in the TripleO CI and Quickstart is welcome to join 
the meeting:


Time: Thursdays, 15:30-16:30 UTC
Place: https://bluejeans.com/4113567798/

Meeting summary:

* The Quickstart transition does not seem to have any blockers or 
bottlenecks for the time being, we are on track to be ready at the end 
of the Ocata cycle, and switch in the beginning of Pike.


* The new Quickstart based OVB jobs are working consistently and 
reliably, though the tinyrpc.server bug affected them just like the 
regular jobs.


* Got our first overcloud deploy today on the Quickstart based nodepool 
multinode jobs, big kudos to bkero and trown for making it happen. The 
verification part still needs work though.


* The experimental queue is overloaded, we will move OVB workloads to 
the multinode jobs once we get them working reliably.


* We might want to change the experimental OVB jobs to run container and 
composable upgrade jobs instead for increased coverage, but we need more 
input on that, we will discuss it on the next TripleO meeting.


* Selecting the proper configuration to use for each gate/period job is 
not optimal, we should rethink the system during the transition to 
Quickstart. This needs a design session. Also we need an up-to-date job 
type - functionality matrix like this[1].


* We voted to keep the meetings on BlueJeans and at 15:30 UTC.

* We will keep tracking the transition work on the RDO Infra Trello 
board with the [Q to U] tags, maybe move to the CI Squad board on Trello 
later. We should also look at Storyboard and see if that would be useful 
to switch to.


Full meeting minutes and notes: 
https://etherpad.openstack.org/p/tripleo-ci-squad-meeting


Best regards,
Attila

[1] https://review.openstack.org/#/c/399269/7/README.md

__
OpenStack Development Mailing 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][diskimage-builder] Status of diskimage-builder

[Paul Belanger]

Greetings,

With the containerization[1] of tripleo, I'd like to know more about the future 
of
diskimage-builder as it relates to the tripleo project. 

Reading the recently approved spec for containers, container (image) builds are
no longer under the control of tripleo; by kolla. Where does this leave
diskimage-builder as a project under tripleo?  I specifically ask, because I'm
wanting to start down the path of using diskimage-builder as an interface to
containers.

Basically, is it time to move diskimage-builder out from the tripleo project
into another, or its own? Or is tripleo wanting to more forward on development
efforts on diskimage-builder.

[1] 
https://specs.openstack.org/openstack/tripleo-specs/specs/ocata/containerize-tripleo-overcloud.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] [kolla] Problem in Ubuntu check when building Kolla base image

[Jeremy Stanley]

On 2017-01-12 15:02:32 - (-), Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote:
[...]
> 2) I don't know why the OSIC Ubuntu mirror is unsigned. I feel
> like it should be a straight clone of Canonical's repos so that
> the baked-in signing key for the Ubuntu base image will just work,
> but presumably it's this way for a reason?

These mirrors have their package indices regenerated at each update
to prevent index inconsistencies which tend to plague other package
mirroring implementations. We've (the Infra team) discussed
switching to directly copying from an official mirror instead and
running some sort of consistency checker before releasing the update
to our mirror network, but so far nobody has found time to finish
work on that solution.

> 3) Specify a custom apt preferences in the gate to allow
> installing unauthenticated packages in the containers (ugly).
[...]

This is what we do currently on our untrusted single-use job nodes.
-- 
Jeremy Stanley


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

[openstack-dev] [all] New deadline for PTG Travel Support Program

[Thierry Carrez]

Hi everyone,

The PTG Travel Support Program helps contributors that are not otherwise
funded to join their team gathering at the Project Teams Gathering. See
http://www.openstack.org/ptg#tab_travel for more explanations.

The Travel Support Program applications were organized in two phases,
and the second (and last) phase is closing very soon. It was originally
set to close on January 15, but we'll accept applications until
end-of-day Tuesday, January 17th. Apply now if you need it:

https://openstackfoundation.formstack.com/forms/travelsupportptg_atlanta

These submissions will be evaluated next week and grantees will be
notified by Friday, January 20th.

NB: People who did not get accepted during the first phase are
automatically re-considered in phase 2, without needing to re-apply.

This email is also the occasion to remind you to register for the event
if you haven't yet!  Prices will increase on January 24 and February 14.
Book now at:

https://pikeptg.eventbrite.com/

Finally, if you haven't booked your hotel yet, I encourage you to book
ASAP in the event hotel itself using the PTG room block. It helps us
keep the costs under control and helps you share the most time with the
event participants. The hotel block closes on January 27. Book now using
this link:

https://www.starwoodmeeting.com/events/start.action?id=1609140999=381BF4AA

Thanks!

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [openstack-ansible] CI/CD and Openstack deployment

[Battaglia, Jarrad]

Hey everyone,

I am wondering how people are running CI/CD solutions for deploying and 
maintaining their Openstack Environments?  I see the description for live 
upgrading from OSIC (https://osic.org/blogs/live-upgrade-openstack), but am 
intrigued by how others have set up their environments.

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] [kolla] Problem in Ubuntu check when building Kolla base image

[Paul Belanger]

On Thu, Jan 12, 2017 at 03:02:32PM -, Edmund Rhudy (BLOOMBERG/ 120 PARK) 
wrote:
> Here at Bloomberg, we're evaluating Kolla to replace our in-house OpenStack 
> deployment system, and one of our requirements is that we be able to do our 
> builds without touching the Internet - everything needs to come from locally 
> hosted repositories. A few weeks ago, I pushed up a PR 
> (https://review.openstack.org/#/c/414639/) to start working on the ability to 
> build Kolla containers while disconnected from the Internet. It doesn't 
> provide complete coverage by any means (though that is the goal, to ensure 
> that every container can be built offline for every base OS image), but I 
> wanted to use it as a starter for further discussion, as well as reducing the 
> amount of stuff we're carrying as local changes on top of upstream Kolla.
> 
> That being said, when I pushed the PR up, it failed the Ubuntu checks. I 
> looked into it, and here's what I found:
> 
> 1) There is a bug in Kolla (https://bugs.launchpad.net/kolla/+bug/1633187) 
> that causes it to ignore any custom sources.list provided when building 
> Debian/Ubuntu containers. You can supply one, and it will be copied into the 
> build context, but because of 
> http://git.openstack.org/cgit/openstack/kolla/tree/docker/base/Dockerfile.j2#n215,
>  only the sources.list files that come with Kolla would be used anyway. 
> Necessarily, because using local mirrors requires providing a custom 
> sources.list, I fixed this bug 
> (https://bugs.launchpad.net/kolla/+bug/1633187).
> 
> 2) The Ubuntu gate checks provide a custom sources.list which redirects the 
> container away from Canonical's mirrors and onto OSIC-hosted mirrors. The 
> OSIC mirror, for whatever reason, is unsigned. In current master Kolla, this 
> sources.list just isn't used, so checks that rebuild the base image will 
> always use archive.ubuntu.com, because that's the mirror that's specified in 
> docker/base/sources.list.ubuntu. Take for example the output of another PR 
> https://review.openstack.org/#/c/411154/ - if you examine 
> http://logs.openstack.org/54/411154/12/check/gate-kolla-dsvm-build-ubuntu-binary-ubuntu-xenial-nv/26627d8/console.html.gz
>  (from the very top), you can see that it's downloading packages from 
> archive.ubuntu.com as part of the base container build, even though 
> http://logs.openstack.org/54/411154/12/check/gate-kolla-dsvm-build-ubuntu-binary-ubuntu-xenial-nv/26627d8/logs/kolla_configs/kolla/sources.list.txt.gz
>  is supplied as sources.list.
> 
This are not OSIC mirrors, but in fact openstack-infra mirrors (stored in AFS).
You are also correct, the packages are not signed, as this is not an official
mirror. It is something in openstack-infra we has talked about fixing, but
haven't done the work for it yet.

> 3) When I fixed the bug described in #1, it meant the unsigned OSIC mirror 
> specified in sources.list suddenly started getting used, and the base 
> container build now fails because the container build process does not allow 
> unauthenticated packages to be installed.
> 
> How can this be fixed? There are a few options:
> 
> 1) Remove the sources.list from the current gate configurations - the way 
> things are currently set up, the Ubuntu gates actually _depend_ on the 
> presence of a bug in Kolla to function if they ever need to build the base 
> Kolla image. This is not good.
> 
> 2) I don't know why the OSIC Ubuntu mirror is unsigned. I feel like it should 
> be a straight clone of Canonical's repos so that the baked-in signing key for 
> the Ubuntu base image will just work, but presumably it's this way for a 
> reason?
> 
The actually reason, we use reprepro[1] for the mirroring. Because we don't want
to release broken mirrors into our test workers, we do some things during the
mirror process.  Specifically, we don't delete packages on the first mirror
attempt.  We log which packages need to be deleted, then on the next loop (2
hours later) we purge those packages from the system.  As a results, we cannot
preserve the gpg keys from upstream.

[1] 
http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/reprepro/reprepro-mirror-update.sh

> 3) Specify a custom apt preferences in the gate to allow installing 
> unauthenticated packages in the containers (ugly).
> 
Yes, this is what we do on all images today[2]. It is not ugly, just want is
needed to make our mirrors work in the gate.

[2] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/scripts/configure_mirror.sh#n194

> Would somebody with knowledge of the Kolla testing infrastructure be so kind 
> as to comment? I brought this up in IRC a few times but could not get much 
> attention on it.
I would recommend joining #openstack-infra to get more information.

I cannot speak for kolla, but adding the changes I suggested fixes your issues.
However, I wouldn't use the ubuntu containers in production, until you rebuilt

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steven Dake (stdake)]

Thierry,

Cool thanks for the leeway here ☺

I agree wholeheartedly with your last sentiment.  If an existing Kolla sub-team 
or an existing project (e.g. the Puppet team) in OpenStack or a new project 
wants to use Kolla images and feels they would operate more effectively without 
the structure Kolla has in place, I personally as a core reviewer don’t want to 
limit that type of activity as long as it fits within the TC’s governance 
rules.  As a core reviewer, I do want to keep what deliverables we currently 
have in place as splitting out deliverables is super disruptive to the Kolla 
project.  Over 60% of the Ocata cycle has been spent just splitting 
kolla-ansible into its own deliverable – meaning we are way behind on 
maintenance and development of our existing deliverables.  Like all things in 
life, my opinion is subject to change in the future.

Regards
-steve


-Original Message-
From: Thierry Carrez 
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, January 12, 2017 at 6:25 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Michał Jastrzębski wrote:
> So from my point of view, while I understand why project separation
> makes sense in the long run, I will argue that at this moment it will
> be hurtful for the project. Our community is still fairly integrated,
> and I'd love to keep it this way a while longer. We haven't yet fully
> cleaned up mess that split of kolla-ansible caused (documentation and
> whatnot). Having small revolution like that again is something that
> would greatly hinder our ability to deliver valuable project, and I
> think for now that should be our priority.

FWIW my email was not meant as an immediate request to split Kolla
because its internal structure goes against the OpenStack project
structure. In particular as long as the Kolla subteams are fine
operating under a single umbrella and being seen as a single "team",
there is no need to change that, that would be a distraction.

I just wanted to explain that a lot of the organizational problems the
Kolla team is going through are caused by this "umbrella" model and that
we designed the current OpenStack project structure precisely to avoid
them. I also don't want to discourage any Kolla subteam (or future
project leveraging Kolla images) which feels like it would operate
better as a separate project team to file for official inclusion.

Cheers!

-- 
Thierry Carrez (ttx)

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


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

Re: [openstack-dev] [tripleo] Mistral Workflow for deriving THT parameters

[Jiri Tomasek]

On 4.1.2017 09:13, Saravanan KR wrote:

Hello,

The aim of this mail is to ease the DPDK deployment with TripleO. I
would like to see if the approach of deriving THT parameter based on
introspection data, with a high level input would be feasible.

Let me brief on the complexity of certain parameters, which are
related to DPDK. Following parameters should be configured for a good
performing DPDK cluster:
* NeutronDpdkCoreList (puppet-vswitch)
* ComputeHostCpusList (PreNetworkConfig [4], puppet-vswitch) (under review)
* NovaVcpuPinset (puppet-nova)

* NeutronDpdkSocketMemory (puppet-vswitch)
* NeutronDpdkMemoryChannels (puppet-vswitch)
* ComputeKernelArgs (PreNetworkConfig [4]) (under review)
* Interface to bind DPDK driver (network config templates)

The complexity of deciding some of these parameters is explained in
the blog [1], where the CPUs has to be chosen in accordance with the
NUMA node associated with the interface. We are working a spec [2], to
collect the required details from the baremetal via the introspection.
The proposal is to create mistral workbook and actions
(tripleo-common), which will take minimal inputs and decide the actual
value of parameters based on the introspection data. I have created
simple workbook [3] with what I have in mind (not final, only
wireframe). The expected output of this workflow is to return the list
of inputs for "parameter_defaults",  which will be used for the
deployment. I would like to hear from the experts, if there is any
drawbacks with this approach or any other better approach.

This workflow will ease the TripleO UI need to integrate DPDK, as UI
(user) has to choose only the interface for DPDK [and optionally, the
number for CPUs required for PMD and Host]. Of-course, the
introspection should be completed, with which, it will be easy to
deploy a DPDK cluster.

There is a complexity if the cluster contains heterogeneous nodes, for
example a cluster having HP and DELL machines with different CPU
layout, we need to enhance the workflow to take actions based on
roles/nodes, which brings in a requirement of localizing the above
mentioned variables per role. For now, consider this proposal for
homogeneous cluster, if there is a value in this, I will work towards
heterogeneous clusters too.

Please share your thoughts.

Regards,
Saravanan KR


[1] https://krsacme.github.io/blog/post/dpdk-pmd-cpu-list/
[2] https://review.openstack.org/#/c/396147/
[3] https://gist.github.com/krsacme/c5be089d6fa216232d49c85082478419
[4] 
https://review.openstack.org/#/c/411797/6/extraconfig/pre_network/host_config_and_reboot.role.j2.yaml

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


We are recently getting quite a lot of requests such as this - of 
bringing up the logic which takes the introspection data and 
pre-populates the parameters with it. This is usable for network 
configuration, storage etc. So as It seems there is a real need for such 
features, TripleO team should discuss general approach on how this logic 
should work. Mistral workflow is an obvious choice, we just need to make 
sure a certain pre-requisities are met.


From the GUI point of view, we probably don't want this type of 
workflow to happen as part of starting the deployment. That's too late. 
We need to find mechanism which helps us to identify when such workflow 
can run and it should probably be confirmed by user. And when it 
finishes, Used needs to be able to review those parameters and confirm 
that this is the configuration he wants to deploy and should be able to 
make changes to it.


Obviously, as this workflow uses introspection data, user could be 
offered to run it when introspection finishes. Problem is that we need 
to verify, that using this workflow is valid for the deployment setup 
user is creating. For example, If this workflow sets parameters which 
are defined in templates which user won't deploy, it is wrong.


So I think that proper way would be to embed this in environment selection:
Environment selection is a step where user does high level deployment 
decisions - selects environments which are going to be used for 
deployment. We could bring in a mechanism (embedded in environment file 
or capabilities-map.yaml maybe?) which would allow GUI to do: 'hey, 
you've just enabled feature Foo, and you have introspection data 
available. Do you wish to pre-configure this feature using this data?' 
On confirmation the workflow is triggered and configuration is 
populated. User reviews it and does tweaks if he wants.


I'd love to hear feedback on this.

--Jirka



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

[openstack-dev] [octavia]redirection and barbican config

[Abed Abu-Dbai]

Hi,

Please consider the bug:

https://bugs.launchpad.net/devstack/+bug/1655656

Thanks,
Abed Abu dbai

__
OpenStack Development Mailing 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] Limitation on port chains + flow classifiers

[Bernard Cafarelli]

On 10 January 2017 at 14:13, Duarte Cardoso, Igor
 wrote:
> Hi networking-sfc,
>
>
>
> While working on the SFC Graphs patch, I observed the following limitation
> when creating port-chains: http://paste.openstack.org/show/594387/.
>
>
>
> My objective was to have 2 port-chains acting on the same classification of
> traffic but from different logical source ports – my expectation was that
> there wouldn’t be any clash here.
>
>
>
> However, the flow-classifiers clash when they are associated to those 2
> different port-chains.
>
>
>
> The exception is raised in [1] and the attributes of the flow-classifier
> being checked are in [2], where neither logical source port or logical
> destination port are specified.
>
>
>
> Is there a specific reasoning behind this or can it be considered a bug? For
> the SFC Graphs work, it’s important that this limitation be lifted – I’m
> happy to submit a patch to correct it.
>
> Let me know your thoughts.
>
>
>
> [1]
> https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
>
> [2]
> https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

This must be the theme for this week's networking-sfc topic then, I
ended up hitting the same problem while anylyzing the tempest race
condition failures [1].

Each test creates a new port to use for its port pair, and a new flow
classifier. The flow classifier has the same parameters, except for
the source logical port (the related port is used here).
Apparently the test failure (a PortChainFlowClassifierInConflict
exception) is caused by a flow classifier from a previous test
conflicting with the new one.

My thoughts here: this should indeed be allowed, and I think this
restriction comes from an incorrect use of the *_conflict() functions
[2]: we should use the full flowclassifier_conflict() instead of
flowclassifier_basic_conflict(), as it adds logical port conflict
check and is the "main" conflict check function.
That is in fact the fix I just sent for review [3], local tempest runs
went fine here. Feedback welcome!


[1] https://bugs.launchpad.net/networking-sfc/+bug/1655618
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191
[3] https://review.openstack.org/#/c/419525/

-- 
Bernard Cafarelli

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

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

[Yujun Zhang]

Hi, Ifat

You comments is quite right. See my additional explanation inline.

On Thu, Jan 12, 2017 at 5:12 PM Afek, Ifat (Nokia - IL) 
wrote:

>
>
> One possible solution would be introducing a high level (abstract)
> template from users view. Then convert it to Vitrage scenario templates (or
> directly to graph). The *more sources* (nagios, vitrage deduction) for an
> abstract alarm we get from the system, the *more confidence* we get for a
> real fault. And the confidence of an alarm could be included in the
> scenario condition.
>
>
>
> [Ifat] I understand your idea, not sure yet if it helps with the use case.
>
> How would you imagine the ‘confidence’ property? As Boolean or a counter?
> One option is ‘deduced’ vs. ‘monitored’.
>
Another option is to count the number of monitors that reported it.
>

'deduced' vs 'monitored' would be good enough for most cases. Unless we
have identify some real use case, I also think there is no need for bring
in quantitative indicator like counter or probability.


> Personally, I don’t think this is needed. I think that if Nagios reports
> an error, then it is confident enough without getting it from another
> monitor.
>

You are right. We would consider a reported alarm as a reliable indicator
of fault. What I was thinking about is: when we the alarm is not seen, can
we be sure there is no fault?

Another situation is slow upstream alarm with fast downstream alarm. I
don't have an actual example for the moment, so please allow me to imagine
an extreme condition.

Suppose host fault will cause instance fault. But due to some restriction,
the host fault is scanned every 1 hour, but instance fault can be scanned
every 1 second. Now, we get alarms from 10 instance in the same host. Can
we deduce that the host is likely in fault status? And we may raise a
"deduced" alarm on the host and trigger an immediate scan which may result
in a "monitored" alarm. In this way, we reduce the time of detecting the
root cause, i.e host fault.

An alternative solution is to distinguish fault from alarm. Alarm is
actually a reflection of fault status.  Beside the directly linked alarm,
fault status can also be deduced from downstream alarms. I haven't think
over this model yet, it just flashed over my mind. Any comments are welcome.
__
OpenStack Development Mailing 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][Mistral][Ansible] Calling Ansible from Mistral workflows

[Dougal Matthews]

Hey all,

I just wanted to share a quick experiment that I tried out. I had heard
there was some interest in native Ansible actions for Mistral. After much
dragging my heels I decided to give it a go, and it turns out to be very
easy.

This code is very raw and has only been lightly tested - I just wanted to
make sure it was going in the right direction and see what everyone thought.

I wont duplicate it all again here, but you can see the details on either
GitHub or a quick blog post that I put together.

https://github.com/d0ugal/mistral-ansible-actions
http://www.dougalmatthews.com/2017/Jan/12/calling-ansible-from-mistral-workflows/

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

[openstack-dev] [kolla] Problem in Ubuntu check when building Kolla base image

[Edmund Rhudy (BLOOMBERG/ 120 PARK)]

Here at Bloomberg, we're evaluating Kolla to replace our in-house OpenStack 
deployment system, and one of our requirements is that we be able to do our 
builds without touching the Internet - everything needs to come from locally 
hosted repositories. A few weeks ago, I pushed up a PR 
(https://review.openstack.org/#/c/414639/) to start working on the ability to 
build Kolla containers while disconnected from the Internet. It doesn't provide 
complete coverage by any means (though that is the goal, to ensure that every 
container can be built offline for every base OS image), but I wanted to use it 
as a starter for further discussion, as well as reducing the amount of stuff 
we're carrying as local changes on top of upstream Kolla.

That being said, when I pushed the PR up, it failed the Ubuntu checks. I looked 
into it, and here's what I found:

1) There is a bug in Kolla (https://bugs.launchpad.net/kolla/+bug/1633187) that 
causes it to ignore any custom sources.list provided when building 
Debian/Ubuntu containers. You can supply one, and it will be copied into the 
build context, but because of 
http://git.openstack.org/cgit/openstack/kolla/tree/docker/base/Dockerfile.j2#n215,
 only the sources.list files that come with Kolla would be used anyway. 
Necessarily, because using local mirrors requires providing a custom 
sources.list, I fixed this bug (https://bugs.launchpad.net/kolla/+bug/1633187).

2) The Ubuntu gate checks provide a custom sources.list which redirects the 
container away from Canonical's mirrors and onto OSIC-hosted mirrors. The OSIC 
mirror, for whatever reason, is unsigned. In current master Kolla, this 
sources.list just isn't used, so checks that rebuild the base image will always 
use archive.ubuntu.com, because that's the mirror that's specified in 
docker/base/sources.list.ubuntu. Take for example the output of another PR 
https://review.openstack.org/#/c/411154/ - if you examine 
http://logs.openstack.org/54/411154/12/check/gate-kolla-dsvm-build-ubuntu-binary-ubuntu-xenial-nv/26627d8/console.html.gz
 (from the very top), you can see that it's downloading packages from 
archive.ubuntu.com as part of the base container build, even though 
http://logs.openstack.org/54/411154/12/check/gate-kolla-dsvm-build-ubuntu-binary-ubuntu-xenial-nv/26627d8/logs/kolla_configs/kolla/sources.list.txt.gz
 is supplied as sources.list.

3) When I fixed the bug described in #1, it meant the unsigned OSIC mirror 
specified in sources.list suddenly started getting used, and the base container 
build now fails because the container build process does not allow 
unauthenticated packages to be installed.

How can this be fixed? There are a few options:

1) Remove the sources.list from the current gate configurations - the way 
things are currently set up, the Ubuntu gates actually _depend_ on the presence 
of a bug in Kolla to function if they ever need to build the base Kolla image. 
This is not good.

2) I don't know why the OSIC Ubuntu mirror is unsigned. I feel like it should 
be a straight clone of Canonical's repos so that the baked-in signing key for 
the Ubuntu base image will just work, but presumably it's this way for a reason?

3) Specify a custom apt preferences in the gate to allow installing 
unauthenticated packages in the containers (ugly).

Would somebody with knowledge of the Kolla testing infrastructure be so kind as 
to comment? I brought this up in IRC a few times but could not get much 
attention on it.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

[Jesse Pretorius]

Hi Sean,

Great to see you taking the initiative on this.

I think the starting point we’d have to work from with the way the builds are 
executed now would be to have the upgrade job execute in a periodic pipeline 
that has a longer timeout. While it would be ideal to do on-commit tests it’s 
just untenable right now as it would severely slow down the workflow.

In terms of using a ‘cached’ or pre-built container rootfs, pre-build wheels 
and venvs, etc this is something that we at Rackspace are working on already 
and are hoping to share some experience with at the Pike PTG. The initial work 
is a bit of a hack job, but we’re hoping to learn enough to share and are 
hoping to collaborate to put together something that can be used by a broader 
community and contributed to by a broader community.

Right now, however, I think we need some sort of upgrade tests on a regular 
basis more than we need to implement an alternative emans of deploying. Our 
choices are therefore, as far as I can see, to have this done in External CI or 
to use OpenStack-Infra’s periodic jobs. Once we have something in place we can 
work towards improving the execution speed (using whatever means available) to 
get to the point where we can usefully execute the jobs on-commit.

J
IRC: odyssey4me

On 1/11/17, 11:03 PM, "Sean M. Collins"  wrote:

OK - with https://review.openstack.org/#/c/418521/ we have at least a
working POC of what we can do.

The issue is that we're running into the Zuul timeout.

Depending on how quickly the AIO is built, we can get to the point where
we run the upgrade script[2].

However in some runs we don't get to the end of the AIO build[3].

So, the question is, how do we proceed? I'm not a real LXC expert but if
we could somehow cache stable builds of the LXC containers, so that
bootstrapping the AIO just means downloading and launching them, so that
we can use the majority of the Zuul runtime to execute the upgrade
script, that'd be great.

I know he have diskimage builder that does something sort of like this,
maybe we can do something similar for the LXC containers?


[1]: 
http://logs.openstack.org/21/418521/7/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/6704087/console.html#_2017-01-11_05_13_16_114022
[2]: 
http://logs.openstack.org/21/418521/7/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/6704087/console.html#_2017-01-11_05_13_24_895056
[3]: 
http://logs.openstack.org/21/418521/8/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/ac09458/console.html#_2017-01-11_21_13_55_572404
--
Sean M. Collins

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




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] placement job is busted in stable/newton (NO MORE HOSTS LEFT)

[Jeremy Stanley]

On 2017-01-11 20:40:26 -0600 (-0600), Matt Riedemann wrote:
[...]
> Well I guess it's less sinister than all that, it was just a matter of when
> the nova change landed, which was meant for newton but happened in Ocata:
[...]

Oh, good catch! I didn't even think to check whether that hook
existed in nova's stable branches, I was only looking at master
because I hadn't paid close enough attention to your subject line.
-- 
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] [glance][tempest][api] community images, tempest tests, and API stability

[Brian Rosmaita]

On 1/11/17 10:35 PM, GHANSHYAM MANN wrote:
> Sorry I could not attend meeting due to TZ.

I wound up missing the meeting, too; I thought it was at 17:00 UTC.

> But from meeting logs, it looks like impression was(if am not wrong) that
> Tempest test[1] is not doing the right thing and should be ok to change.
> I do not think this is the case, Tempest test is doing what API
> tells/behave. Below is what test does:
>  1. Tenant A creates image with explicitly visibility as private.
>  2. Tenant A add Tenant B as member of created image to allow Tenant B to
> use that.
> 
> API [2] or Image sharing workflow [3] does not say/recommend anywhere that
> Image should not be created with private visibility as explicitly.
> 
> For me this change breaks people "Creating Image with private visibility as
> *explicitly* and adding member to that" which will be 409 after glance
> proposal.
>
> 
> Also changing tempest tests does not solve the problem, backward
> incompatible is still will be introduced in API.

The issue is that we are proposing to introduce an incompatible change
in order to address an incoherence with image visibility semantics.  We
have acknowledged that this is a breaking change, but the impact of the
change is mitigated by the way that the default visibility value is
assigned in Ocata.

As I've documented earlier in the thread, we have discussed this change
with the wider community and the API Working Group, and they are OK with it.

The current tempest test has done its duty and identified an
incompatibility in the Ocata code.  We acknowledge that and salute you.
On balance, however, this change will be better for users (and as I've
documented earlier in the thread, we've minimized the impact of the
change), and we want to make it anyway.

So the situation isn't that we are claiming that your current code is
flawed.  Rather, it is that we are asking the QA team to approve a
change to that test in order to address a change we are making in Ocata,
a change that has the support of the OpenStack community.

thanks,
brian

> 
> .. 1
> http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/image/v2/test_images.py#n338
> 
> .. 2 http://developer.openstack.org/api-ref/image/v2/#create-an-image
> .. 3
> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
> 
> 
> Regards
> Ghanshyam Mann
> +818011120698
>
> 
> On Mon, Jan 9, 2017 at 10:30 PM, Brian Rosmaita 
> wrote:
> 
>> On 1/5/17 10:19 AM, Brian Rosmaita wrote:
>>> To anyone interested in this discussion: I put it on the agenda for
>>> today's API-WG meeting (16:00 UTC):
>>>
>>> https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
>>
>> As you probably noticed in the API-WG newsletter [A], this issue was
>> discussed at last week's API-WG meeting.  The complete discussion is in
>> the meeting log [B], but the tldr; is that the proposed change is
>> acceptable.  I'll address specific points inline for those who are
>> interested, but the key request from the Glance team right now is that
>> the QA team approve this patch:
>>
>> https://review.openstack.org/#/c/414261/
>>
>>
>> [A]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-
>> January/109698.html
>> [B]
>> http://eavesdrop.openstack.org/meetings/api_wg/2017/api_
>> wg.2017-01-05-16.00.log.html
>>
>>> On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
 Thanks Brian for bringing this up, same we been discussing last week on
>> QA
 channel and this patch[1] but I completely agree with Matthew opinion
>> here.
 There is no doubt that this change(4-valued) are much better and clear
>> than
 old one. This makes much defined and clear way of defining the image
 visibility by/for operator/user.
>>
>> Yes, we think that the change clarifies the visibility semantics of
>> images and, in particular, fixes the problem of there being "private"
>> images that aren't actually private.
>>
>> The current situation is easily misunderstood by end users, as evidenced
>> by bugs that have been filed, for example,
>> https://bugs.launchpad.net/glance/+bug/1394299
>> https://bugs.launchpad.net/glance/+bug/1452443
>>
 Upgrade procedure defined in all referenced ML/spec looks fine for
 redefining the visibility for images with or without members to
 shared/private. Operator feedback/acceptance for this change makes it
 acceptable.
>>
>> Thanks, we discussed this thoroughly and solicited operator feedback.
>>
 But operator/users creating images with visibility as "private"
 *explicitly*, this changes is going to break them:

 - Images with member already added in that would not
>> works
 as Tempest tests does [2].

 - They cannot add member as they used to do that.
>>
>> Yes, we recognize that this change will introduce an incompatibility in
>> the workflow for users who are setting visibility explicitly to
>> 'private' upon image creation.  The 

Re: [openstack-dev] updating to pycryptome from pycrypto

[Ian Cordasco]

-Original Message-
From: Ian Cordasco 
Reply: Ian Cordasco 
Date: January 11, 2017 at 11:09:11
To: OpenStack Development Mailing List (not for usage questions)

Subject:  Re: [openstack-dev] updating to pycryptome from pycrypto

> -Original Message-
> From: Matthew Thode
> Reply: prometheanf...@gentoo.org , OpenStack Development
> Mailing List (not for usage questions)
> Date: January 11, 2017 at 04:53:41
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] updating to pycryptome from pycrypto
>
> > So, pycrypto decided to rename themselves a while ago. At the same time
> > they did an ABI change. This is causing projects that dep on them to
> > have to handle both at the same time. While some projects have
> > migrated, most have not.
> >
> > A problem has come up where a project has a CVE (pysaml2) and the fix is
> > only in versions after they changed to pycryptome. This means that in
> > order to consume the fix in a python-native way all the pycrypto
> > dependency would need to be updated to pycryptome in all projects in the
> > same namespace that pysaml2 is installed.
> >
> > Possible solutions:
> >
> > update everything to pycryptome
> > * would be the best going forward
> > * a ton of work very late in the cycle
> >
> > have upstream pysaml2 release a fix based on the code before the change
> > * less work
> > * should still circle around and update the world in pike
> > * 4.0.2 was the last release 4.0.3 was the change
> > * would necessitate a 4.0.2.1 release
> > * tag was removed, can hopefully be recovered for checkout/branch
> >
> >
> > Here's the upstream bug to browse at your leisure :)
> >
> > https://github.com/rohe/pysaml2/issues/366
>
> I don't think pycrypto actually willfully renamed itself. [1] As I understand 
> it, pycryptome
> is a fork of pycrypto made after pycrypto decided that they wanted to tell 
> people to use
> pyca/cryptography instead. Frankly, given pycrypto's history (and the history 
> that
> pycryptome has probably inherited), I'd suspect that the best effort for 
> those of us
> interested, is to help pysaml2 express the deficits it has with cryptography 
> so it can
> move to a better project. If there are no deficits, then we should focus on 
> helping pysaml2
> port to cryptography.
>
>
> [1]: I'm verifying this with some people who know better

So I did verify that there are *several* hostile forks of PyCrypto.
That said, the work to move pysaml2 to cryptography has been finished:
https://github.com/rohe/pysaml2/pull/385

I'd ask OpenStackers to not start a brigade of +1s on the thread, but
if y'all want to watch it and help convince the maintainer (*if* they
need convincing) to merge this, that would be appreciated.

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing 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][kolla] Adding new deliverables

[Thierry Carrez]

Michał Jastrzębski wrote:
> So from my point of view, while I understand why project separation
> makes sense in the long run, I will argue that at this moment it will
> be hurtful for the project. Our community is still fairly integrated,
> and I'd love to keep it this way a while longer. We haven't yet fully
> cleaned up mess that split of kolla-ansible caused (documentation and
> whatnot). Having small revolution like that again is something that
> would greatly hinder our ability to deliver valuable project, and I
> think for now that should be our priority.

FWIW my email was not meant as an immediate request to split Kolla
because its internal structure goes against the OpenStack project
structure. In particular as long as the Kolla subteams are fine
operating under a single umbrella and being seen as a single "team",
there is no need to change that, that would be a distraction.

I just wanted to explain that a lot of the organizational problems the
Kolla team is going through are caused by this "umbrella" model and that
we designed the current OpenStack project structure precisely to avoid
them. I also don't want to discourage any Kolla subteam (or future
project leveraging Kolla images) which feels like it would operate
better as a separate project team to file for official inclusion.

Cheers!

-- 
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] 答复: [heat] glance v2 support?

[Zane Bitter]

On 11/01/17 10:01, Thomas Herve wrote:

On Wed, Jan 11, 2017 at 3:34 PM, Emilien Macchi  wrote:

On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve  wrote:

I think this is going where I thought it would: let's not do anything.
The image resource is there for v1 compatibility, but there is no
point to have a v2 resource, at least right now.


If we do nothing, we force our heat-template users to keep Glance v1
API enabled in their cloud (+ running Glance Registry service), which
at some point doens't make sense, since Glance team asked to moved
forward with Glance v2 API.

I would really recommend to move forward and stop ignoring the new API version.


Emilien was right: by defaulting to Glance v1, we still required it
for the image constraint, which is used everywhere like servers and
volumes. We can easily switch to v2 for this, I'll do it right away.


For those following along at home, this merged: 
https://review.openstack.org/#/c/418987/


Patch to deprecate the resource type: 
https://review.openstack.org/#/c/419043/


- ZB

__
OpenStack Development Mailing 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] Reminder: TripleO deep dive "how to contribute to the tripleo ui" starts in 2 hours

[Ana Krivokapic]

Hope to see many of you there!

https://etherpad.openstack.org/p/tripleo-deep-dive-ui


-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Takashi Yamamoto]

On Thu, Dec 1, 2016 at 1:02 AM, Armando M.  wrote:
>
>
> On 27 November 2016 at 20:50, Takashi Yamamoto 
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>
>
> That's great to hear Yamamoto. Since you are already a neutron-core I assume
> you are already intimate with the work required to strengthen the VPNaaS
> project. I have added you to [4] and you can lean on me for any changes that
> needs reviewing.

these fixes for gate jobs need review:
https://review.openstack.org/#/c/410511/
https://review.openstack.org/#/c/410530/
https://review.openstack.org/#/c/419396/

>
>>
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing 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] How change a section name in oslo.config but keep compatibility with the old format

[Maxime Cottret]

 

Thanks jordan for the quick answer, it looks interesting. 

I forgot
a detail: the section name is defined when registering options with the
cfg.CONF.register_opts method. 

--
Maxime Cottret - Consultant
Cloud/DataOps @ OBJECTIF-LIBRE

Mail :
maxime.cott...@objectif-libre.com
Tel : 05 82 95 65 36 (standard)
Web :
www.objectif-libre.com Twitter: @objectiflibre

Le 2017-01-12 11:35,
Jordan Pittier a écrit : 

> Hi,
> 
> Look at this file
>
https://github.com/openstack/tempest/blob/master/tempest/config.py [3]
and
> search for "deprecated_opts" Not sure you can deprecate a whole
>
section, but you can set the old location (old section/old config
>
name) for each new config option.
> 
> On Thu, Jan 12, 2017 at 11:01 AM,
Maxime Cottret
>  wrote:
> 
>> Hi
every one, I'm a new developer on Cloudkitty project and I was wondering
how I can depreciate a section name in oslo.config. I'd like to rename a
section for consistency and depreciate the old name before removing its
use in the next cycle. I've looked into oslo.config documentation but
couldn't manage a way to do it. Thanks in advance for your help. Regards
-- Maxime Cottret - Consultant Cloud/DataOps @ OBJECTIF-LIBRE Mail :
maxime.cott...@objectif-libre.com Tel : 05 82 95 65 36 (standard) Web :
www.objectif-libre.com [1] Twitter: @objectiflibre
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2]



Links:
--
[1] http://www.objectif-libre.com
[2]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[3]
https://github.com/openstack/tempest/blob/master/tempest/config.py
__
OpenStack Development Mailing 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] How change a section name in oslo.config but keep compatibility with the old format

[Jordan Pittier]

Hi,

Look at this file
https://github.com/openstack/tempest/blob/master/tempest/config.py and
search for "deprecated_opts" Not sure you can deprecate a whole
section, but you can set the old location (old section/old config
name) for each new config option.

On Thu, Jan 12, 2017 at 11:01 AM, Maxime Cottret
 wrote:
> Hi every one,
>
> I'm a new developer on Cloudkitty project and I was wondering how I can
> depreciate a section name in oslo.config.
>
> I'd like to rename a section for consistency and depreciate the old name
> before removing its use in the next cycle.
>
> I've looked into oslo.config documentation but  couldn't manage a way to do
> it.
>
> Thanks in advance for your help.
>
> Regards
>
> --
> Maxime Cottret - Consultant Cloud/DataOps @ OBJECTIF-LIBRE
>
> Mail : maxime.cott...@objectif-libre.com
> Tel : 05 82 95 65 36 (standard)
> Web : www.objectif-libre.com Twitter: @objectiflibre
>
>
> __
> OpenStack Development Mailing 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] How change a section name in oslo.config but keep compatibility with the old format

[Maxime Cottret]

 

Hi every one, 

I'm a new developer on Cloudkitty project and I was
wondering how I can depreciate a section name in oslo.config. 

I'd like
to rename a section for consistency and depreciate the old name before
removing its use in the next cycle. 

I've looked into oslo.config
documentation but couldn't manage a way to do it. 

Thanks in advance
for your help. 

Regards 

--
Maxime Cottret - Consultant Cloud/DataOps
@ OBJECTIF-LIBRE

Mail : maxime.cott...@objectif-libre.com
Tel : 05 82
95 65 36 (standard)
Web : www.objectif-libre.com Twitter:
@objectiflibre
 __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] networking-sfc stable/newton branch broken

[Bernard Cafarelli]

On 12 January 2017 at 03:28, Armando M.  wrote:
> Hi,
>
> Please have a look at [1]. The branch has been broken for some time now.
>
> Thanks,
> Armando
>
> [1]
> https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc+branch:stable/newton

Indeed, it needs two fixes on the tempest gate: one is ready for
backport [1], the other I am still working on [2]

[1] https://review.openstack.org/#/c/418926/
[2] https://bugs.launchpad.net/networking-sfc/+bug/1655618


-- 
Bernard Cafarelli

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

Re: [openstack-dev] [nova] Inconsistency of parameter type in Nova API Reference

[Takashi Natsume]

On 2017/01/10 20:35, Sean Dague wrote:

On 01/10/2017 01:39 AM, Takashi Natsume wrote:

Hi Nova developers.

In Nova API Reference(*1),
the following parameters' values are 'null' in HTTP request body samples.
And their parameter types are defined as 'string'.

* 'confirmResize' parameter in "Confirm Resized Server (confirmResize
Action)"
* 'lock' parameter in "Lock Server (lock Action)"
* 'pause' parameter in "Pause Server (pause Action)"
* 'resume' parameter in "Resume Suspended Server (resume Action)"
* 'revertResize' parameter in "Revert Resized Server (revertResize Action)"
* 'os-start' parameter in "Start Server (os-start Action)"
* 'os-stop' parameter in "Stop Server (os-stop Action)"
* 'suspend' parameter in "Suspend Server (suspend Action)"

On the other hand,
the following parameter's value is 'null' in the HTTP request body sample.
But the parameter type is defined as 'none'.

* 'trigger_crash_dump' in "Trigger Crash Dump In Server"

IMO, there is inconsistency of parameter types.
Should they be unified as 'none'?


+1. 'none' seem appropriate here and not confuse this with strings.

-Sean


Thank you for your reply.
I will replace 'string' with 'none' in the parameters.

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp



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

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

[Afek, Ifat (Nokia - IL)]

Hi Yujun,

See my comments inline.

Ifat.

From: Yujun Zhang 
Date: Wednesday, 11 January 2017 at 12:12


I have just realized abstract alarm is not a good term. What I was talking 
about is fault and alarm.

Fault is what actually happens, and alarm is how it is detected (or deduced).


On Wed, Jan 11, 2017 at 5:13 PM Yujun Zhang 
> wrote:

I think YinLiYin's idea is a reasonable requirement from end user. They care 
more about the real faults in the system, not how they are detected. Though it 
will bring much challenge to design and engineering, it creates value for 
customers. I'm quite positive on this evolution.

[Ifat] Of course. I never argued about the need, just tried to figure out how 
we should implement it.

One possible solution would be introducing a high level (abstract) template 
from users view. Then convert it to Vitrage scenario templates (or directly to 
graph). The more sources (nagios, vitrage deduction) for an abstract alarm we 
get from the system, the more confidence we get for a real fault. And the 
confidence of an alarm could be included in the scenario condition.

[Ifat] I understand your idea, not sure yet if it helps with the use case.
How would you imagine the ‘confidence’ property? As Boolean or a counter? One 
option is ‘deduced’ vs. ‘monitored’. Another option is to count the number of 
monitors that reported it. Personally, I don’t think this is needed. I think 
that if Nagios reports an error, then it is confident enough without getting it 
from another monitor.


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

Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml

[Yurii Prokulevych]

Hi Srikanth,

As U've noticed those meters are derived from notifications emitted by
other OpenStack services. So please check that 'cord.dns.cache.size'
events are processed correctly.

Also, the last sentences from the guide:
'''
These meters are not loaded by default. 
To load these meters, flip the `disable_non_metric_meters` option in
the ceilometer.conf file '''

Do U have this enabled ?

---
Regards,
Yurii


On Thu, 2017-01-12 at 02:01 +, Srikanth Vavilapalli wrote:
> Hi
> 
> I was following the instructions @ http://docs.openstack.org/admin-gu
> ide/telemetry-data-collection.html#meter-definitions to add new
> meters to Ceilometer, but not able to make it work.
> 
> I verified meters.yaml file in meter/data folder:
> 
> ubuntu@mysite-ceilometer-3:/usr/lib/python2.7/dist-
> packages/ceilometer/meter/data$ ls
> meters.yaml
> 
> 
> I add the following new meter to the end of that file:
> 
>   - name: $.payload.name
> event_type: 'cord.dns.cache.size'
> type: 'gauge'
> unit: 'entries'
> volume: $.payload.cache_size
> user_id: $.payload.user_id
> project_id: $.payload.project_id
> resource_id: '"cord-" + $.payload.base_id'
> 
> When I inject 'cord.dns.cache.size' metric from a sample publisher to
> rabbitmq server (@ exchange 'openstack') on which the ceilometer
> notification agents are listening, I don't see these metrics
> appearing in 'ceilometer meter-list' output. Can any one plz let me
> know if I missing any config or change that prevents custom meter
> processing in Ceilometer?
> 
> Appreciate ur inputs.
> 
> Thanks
> Srikanth
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] 答复: [heat] glance v2 support?

[Flavio Percoco]

On 11/01/17 16:01 +0100, Thomas Herve wrote:

On Wed, Jan 11, 2017 at 3:34 PM, Emilien Macchi  wrote:

On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve  wrote:

I think this is going where I thought it would: let's not do anything.
The image resource is there for v1 compatibility, but there is no
point to have a v2 resource, at least right now.


If we do nothing, we force our heat-template users to keep Glance v1
API enabled in their cloud (+ running Glance Registry service), which
at some point doens't make sense, since Glance team asked to moved
forward with Glance v2 API.

I would really recommend to move forward and stop ignoring the new API version.


Emilien was right: by defaulting to Glance v1, we still required it
for the image constraint, which is used everywhere like servers and
volumes. We can easily switch to v2 for this, I'll do it right away.


Thanks, Thomas!

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