Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

[Valeriy Ponomaryov]

For the moment Manila does following:
- creates Neutron port, consider "reserves" network info.
- then calls its own share driver that supports network handling and that
driver does binding on its backend.
- Neutron does not have info about real usage of a port and its info.

So, it is correct to say that "bind" operation is performed by each Manila
share driver on its own way. Manila common code (not share-driver-specific)
does only "reservation" for now.
Would be good to have common possibility to write "bind" info to Neutron
that was performed by Manila. It is very undesired to write separate
Neutron driver for each Manila backend that supports networking.

Valeriy

On Tue, Mar 1, 2016 at 7:22 AM, Kevin Benton  wrote:

> >This seems gross and backwards. It makes sense as a short term hack but
> given that we have time to design this correctly I'd prefer to get this
> information in a more straighforward way.
>
> Well it depends on what is happening here. If Manilla is wiring up a
> specific VLAN for a port, that makes it part of the port binding process,
> in which case it should be an ML2 driver. Can you provide some more details
> about what Manilla is doing with this info?
>
> On Mon, Feb 29, 2016 at 5:29 PM, Ben Swartzlander 
> wrote:
>
>> On 02/29/2016 04:38 PM, Kevin Benton wrote:
>>
>>> You're correct. Right now there is no way via the HTTP API to find which
>>> segments a port is bound to.
>>> This is something we can certainly consider adding, but it will need an
>>> RFE so it wouldn't land until Newton at the earliest.
>>>
>>
>> I believe Newton is the target for this work. This is feature freeze week
>> after all.
>>
>> Have you considered writing an ML2 driver that just notifies Manilla of
>>> the port's segment info? All of this information is available to ML2
>>> drivers in the PortContext object that is passed to them.
>>>
>>
>> This seems gross and backwards. It makes sense as a short term hack but
>> given that we have time to design this correctly I'd prefer to get this
>> information in a more straighforward way.
>>
>> -Ben Swartzlander
>>
>>
>> On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka >> > wrote:
>>>
>>> Fixed neutron tag in the subject.
>>>
>>> Marc > wrote:
>>>
>>> Hi Neutron team,
>>>
>>> I am currently working on a feature for hierarchical port
>>> binding support in
>>> Manila [1] [2]. Just to give some context: In the current
>>> implementation Manila
>>> creates a neutron port but let it unbound (state DOWN).
>>> Therefore Manila uses
>>> the port create only retrieve an IP address and segmentation ID
>>> (some drivers
>>> only support VLAN here).
>>>
>>> My idea is to change this behavior and do an actual port binding
>>> action so that
>>> the configuration of VLAN isn’t a manual job any longer. And
>>> that multi-segment
>>> and HPB is supported on the long-run.
>>>
>>> My current issue is: How can Manila retrieve the segment
>>> information for a
>>> bound port? Manila only is interested in the last (bottom)
>>> segmentation ID
>>> since I assume the storage is connected to a ToR switch.
>>>
>>> Database-wise it’s possible to query it using
>>> ml2_port_binding_levels table.
>>> But AFAIK there is no API to query this. The only information
>>> that is exposed
>>> are all segments of a network. But this is not sufficient to
>>> identify which
>>> segments actually used for a port binding.
>>>
>>> Regards
>>> Marc
>>> SAP SE
>>>
>>> [1]:
>>>
>>> https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support
>>> [2]: https://review.openstack.org/#/c/277731/
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> <
>>> http://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://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] [nova] Should we cleanup migration from virt drivers?

[Eli Qiao]

hello Nova hackers

I see in some of virt drivers (see belows links) 's 
confirm_resize/revert_resize(or something like that) passing a parameter 
'migration',
but it is not used at all in virt layer drivers, I wonder why we still 
keep them (to reserved for future usage)? can we do a cleanup?
IMO, migration status should be maintained by nova compute layer instead 
of virt layer.


https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/vmops.py#L1372
https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L137
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7437

--
Best Regards, Eli(Li Yong)Qiao
Intel OTC China

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

Re: [openstack-dev] [tricircle] playing tricircle with devstack under two-region configuration

[Yipei Niu]

Hi, all,

I don't know why I clone an old version of devstack, which hasn't been
influenced by the patch. Hence, I install devstack in two nodes
successfully. I think I know how to fix it.

BTW, Zhiyuan's solution to solving the problem in my last mail works. Thank
you for your help.

Best regards,
Yipei

On Tue, Mar 1, 2016 at 11:14 AM, Vega Cai  wrote:

> Hi, All,
>
> Let's move the discussion to #openstack-tricircle in IRC.
>
> BR
> Zhiyuan
>
> On 1 March 2016 at 11:07, Yipei Niu  wrote:
>
>> Hi, all,
>>
>> The bug of deploying devstack with two-node configuration is already
>> fixed. According to the official document, I have already installed
>> devstack in two nodes successfully.
>>
>> Moreover, I am still trying to play tricircle in two nodes. When
>> installing tricircle to node1, I still encounter the same error as before.
>> The link is http://paste.openstack.org/show/488682/.
>>
>> Best regards,
>> Yipei
>>
>> On Tue, Mar 1, 2016 at 10:56 AM, joehuang  wrote:
>>
>>> Hi, Yipei,
>>>
>>>
>>>
>>> The issue is that the OS_REGION_NAME should be “Pod2” for the Node2 for
>>> Nova,Cinder, Neutron endpoint registration in KeyStone, but when creating
>>> endpoint in Keystone, devstack will use command like “openstack endpoint
>>> create” to access KeyStone, the OS_REGION_NAME should be the region name
>>> where the KeyStone located, in two-nodes installation, it should be
>>> “RegionOne” for the command itself.
>>>
>>>
>>>
>>> So it can be fixed by adding one more configurable global variable to
>>> separate KeyStone region name and other services(Nova,Cinder,Neutron)
>>> region name.
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Chaoyi Huang ( Joe Huang )
>>>
>>>
>>>
>>> *From:* Yipei Niu [mailto:newy...@gmail.com]
>>> *Sent:* Monday, February 29, 2016 10:02 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Cc:* Vega Cai; joehuang; 时鹏飞
>>> *Subject:* Re: [tricircle] playing tricircle with devstack under
>>> two-region configuration
>>>
>>>
>>>
>>> Hi Pengfei,
>>>
>>>
>>>
>>> I also encounter the same error when installing devstack on node2. I
>>> insert a command "export OS_REGION_NAME=Pod2" in line 1262 in stack.sh and
>>> it works. However, I am not sure whether it is correct. I am trying to
>>> verify it. Recently, I try to re-install devstack on node1, but I encounter
>>> some errors. The link is http://paste.openstack.org/show/488005/. Do
>>> you have any suggestion about it?
>>>
>>>
>>>
>>> To Joe and Zhiyuan, could you please give me some advice about how to
>>> solve it?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Yipei
>>>
>>>
>>>
>>> On Wed, Feb 24, 2016 at 9:29 AM, Yipei Niu  wrote:
>>>
>>> Hi Joe and Zhiyuan,
>>>
>>>
>>>
>>> My VM has recovered. When I re-install devstack in node1, I encounter
>>> the following errors.
>>>
>>>
>>>
>>> The info in stack.sh.log is as follows:
>>>
>>>
>>>
>>> 2016-02-23 11:18:27.238 | Error: Service n-sch is not running
>>>
>>> 2016-02-23 11:18:27.238 | +
>>> /home/stack/devstack/functions-common:service_check:L1625:   '[' -n
>>> /opt/stack/status/stack/n-sch.failure ']'
>>>
>>> 2016-02-23 11:18:27.238 | +
>>> /home/stack/devstack/functions-common:service_check:L1626:   die 1626 'More
>>> details about the above errors can be found with screen, with
>>> ./rejoin-stack.sh'
>>>
>>> 2016-02-23 11:18:27.238 | +
>>> /home/stack/devstack/functions-common:die:L186:   local exitcode=0
>>>
>>> 2016-02-23 11:18:27.239 | [Call Trace]
>>>
>>> 2016-02-23 11:18:27.239 | ./stack.sh:1354:service_check
>>>
>>> 2016-02-23 11:18:27.239 | /home/stack/devstack/functions-common:1626:die
>>>
>>> 2016-02-23 11:18:27.261 | [ERROR]
>>> /home/stack/devstack/functions-common:1626 More details about the above
>>> errors can be found with screen, with ./rejoin-stack.sh
>>>
>>> 2016-02-23 11:18:28.271 | Error on exit
>>>
>>> 2016-02-23 11:18:28.953 | df: '/run/user/112/gvfs': Permission denied
>>>
>>>
>>>
>>> The info in n-sch.log is as follows:
>>>
>>>
>>>
>>> stack@nyp-VirtualBox:~/devstack$ /usr/local/bin/nova-scheduler
>>> --config-file /et ^Mc/nova/nova.conf & echo $!
>>> >/opt/stack/status/stack/n-sch.pid; fg || echo "n-sch ^M failed to start" |
>>> tee "/opt/stack/status/stack/n-sch.failure"
>>>
>>> [1] 29467
>>>
>>> /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
>>>
>>> 2016-02-23 19:13:00.050 ^[[00;32mDEBUG oslo_db.api [^[[00;36m-^[[00;32m]
>>> ^[[01;35m^[[00;32mLoading backend 'sqlalchemy' from
>>> 'nova.db.sqlalchemy.api'^[[00m ^[[00;33mfrom (pid=29467) _load_backend
>>> /usr/local/lib/python2.7/dist-packages/oslo_db/api.py:238^[[00m
>>>
>>> 2016-02-23 19:13:00.300 ^[[01;33mWARNING
>>> oslo_reports.guru_meditation_report [^[[00;36m-^[[01;33m]
>>> ^[[01;35m^[[01;33mGuru mediation now registers SIGUSR1 and SIGUSR2 by
>>> default for backward compatibility. SIGUSR1 will no longer be registered in
>>> a future release, so please use SIGUSR2 to generate reports.^[[00m
>>>
>>> 

Re: [openstack-dev] [TripleO] core members for tripleo-ui

[Marios Andreou]

On 29/02/16 17:27, Dan Prince wrote:
> There is a new projects for the ui called tripleo-ui. As most of the
> existing TripleO core members aren't going to be reviewing UI specific
> patches is seems reasonable that we might add a few review candidates
> who can focus specifically on UI specific patches.
> 
> I'd like to proposed we add Jiri Tomasek and Ana Krivokapic as core
> candidates that will focus primarily on the UI. They would be added to
> tripleo core but would agree to only +2 patches within the UI for now,
> or at least until they are re-nominated for more general TripleO core,
> etc.
> 
> Core members if you could please vote on this so we can add these
> members at the close of this week. Thanks,

+1

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


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

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

[Ton Ngo]

There seems to be different concerns, so it would be helpful to consider
them separately:
   Ability to accommodate different distros
   How to support given limited resources:  gate tests, developers

   From the discussion at the midcycle, I think we do have agreement that
Magnum must be able to accommodate multiple distros in the form of
"drivers".  What a driver looks like is yet to be designed but it would
likely include images, templates, scripts, template definition, etc.  An
example was articulated for the use case:  financial institutions have
strict policy about the specific distros that have been certified for their
use, and will insist on using their own images.  Having worked with banking
customers before, I can attest to this kind of hard restriction, and we
would expect these users to develop their own drivers.
   Magnum current support for the various distros is somewhat ad hoc, but
going forward, I am sure we will develop a well designed structure for a
distro driver and refactor the current code to fit this structure.  Then
looking at the current code base, we will probably have drivers for Fedora,
Fedora Atomic, CoreOs, Ubuntu.  RHEL would be a good exercise to test drive
creating a new driver.

   This leads to the concern of how to properly support all these drivers
given the limited resources for the project.  For a community based
project, support is driven by interest in the community, so the level of
support will inevitably be uneven. Over time, something that attracts no
interest will eventually be removed, but we should be careful not to remove
things prematurely.
   We can think of several ways to cope with the varied level of support.
   One way is to have an indication of the maturity of each drivers
(similarly to how OpenStack projects are rated).  This can be based on some
metrics like number of tests, or could also be just a qualitative
description like "high, medium, low".  This would help users to choose what
to use, or to invest in development if there is interest.
   Another way is to select a few key drivers as fully supported, and put
the remaining in a contrib directory to indicate that support for these is
on a best effort basis.  Drivers can be moved around as interest changes
over time.

Ton,




From:   王华 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   02/29/2016 06:30 PM
Subject:Re: [openstack-dev] [magnum] Discussion of supporting
single/multiple OS distro



I think users need the support for multiple OS choices. Users may want to
modify the OS by themselves to meet the requirement of their business. If
Magnum only supports a single OS distro, we should have a  convenient way
to change one OS distro to another. But the OSes are so different, the work
is difficult. So if Magnum only supports a single OS distro, the users are
locked into one OS distro.

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


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

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

[Juan Antonio Osorio]

On Tue, Mar 1, 2016 at 12:23 AM, Matt Riedemann 
wrote:

>
>
> On 2/29/2016 2:54 PM, Sean Dague wrote:
>
>> On 02/29/2016 11:59 AM, Sean Dague wrote:
>>
>>> The nova/hooks.py infrastructure has been with us since early Nova. It's
>>> currently only annotated on a few locations - 'build_instance',
>>> 'create_instance', 'delete_instance', and 'instance_network_info'. It's
>>> got a couple of unit tests on it, but nothing that actually tests real
>>> behavior of the hooks we have specified.
>>>
>>> It does get used in the wild, and we do break it with changes we didn't
>>> ever anticipate would impact it -
>>> https://bugs.launchpad.net/nova/+bug/1518321
>>>
>>> However, when you look into how that is used, it's really really odd and
>>> fragile -
>>>
>>> https://github.com/richm/rdo-vm-factory/blob/master/rdo-ipa-nova/novahooks.py#L248
>>>
>>>
>>>  def pre(self, *args, **kwargs):
>>>  # args[7] is the injected_files parameter array
>>>  # the value is ('filename', 'base64 encoded contents')
>>>  ipaotp = str(uuid.uuid4())
>>>  ipainject = ('/tmp/ipaotp', base64.b64encode(ipaotp))
>>>  args[7].extend(self.inject_files)
>>>  args[7].append(ipainject)
>>>
>>> In our continued quest on being more explicit about plug points it feels
>>> like we should other document the interface (which means creating
>>> stability on the hook parameters) or we should deprecate this construct
>>> as part of a bygone era.
>>>
>>> I lean on deprecation because it feels like a thing we don't really want
>>> to support going forward, but I can go either way.
>>>
>>> -Sean
>>>
>>> P.S. I'm starting to look at in tree functional testing for all of this,
>>> in the event that we decide not to deprecate it. It's definitely made a
>>> little hard by the way all exceptions are caught when hooks go wrong.
>>>
>>
>> As there seemed to be some early enthusiasm for this from the core team,
>> the deprecation patch is proposed here -
>> https://review.openstack.org/#/c/286276/
>>
>> Unless there is a big reversal of sentiment I'd suggest we get that
>> landed in Mitaka so that this is signalled to people going forward, and
>> we can collect use cases for things that are currently using hooks that
>> we may want to support in other ways in Newton.
>>
>> -Sean
>>
>>
> I think you should probably also post this to the operators mailing list
> before we actually deprecate hooks.


I agree with Matt, I think this should get more visibility with the
operators first before deprecating it.


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



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

[openstack-dev] [all][log] Ideas to log request-ids in cross-projects

[Kekane, Abhishek]

Hi Devs,

Considering return request-id to caller specs [1] is implemented in
python-*client, I would like to begin discussion on how these request-ids
will be logged in cross-projects. In logging work-group meeting (11-Nov-2015)
[2] there was a discussion about how to log request-id in the log messages.
In same meeting it wass decided to write oslo.log specs but as of now no specs 
has been submitted.

I would like to share our approach to log request-ids and seek suggestions
for the same. We are planning to use request_utils module [3] which was
earlier part of oslo-incubator but removed as no one was using it.

A typical use case is: Tempest asking Nova to perform some action and Nova
calling Glance internally, then the linkages might look like this:

RequestID mapping in nova for nova and glance:
-

INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] Request 
ID Link: request.link 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' -> 
Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43

RequestID mapping in tempest for tempest and nova:
-

INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] 
Request ID Link: request.link 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4' -> 
Target='nova' TargetId=req-f0fb885b-18a2-4510-9e85-b9066b410ee4

As there is a reference of nova's request-id in tempest and glance's
request-id in nova, operator can easily trace the cause of failure.

Using request_utils module we can also mention the 'stage' parameter to
divide the entire api cycle with stages, e.g. create server can be
staged as start, get-image can be staged as download-image and active instance
can be staged as end of the operation.

Advantages:
---

With stages provided for API, it's easy for the operator to find out the 
failure stage from entire API cycle.

An example with 'stage' is,
Tempest asking Nova to perform some action and Nova calling Glance internally,
then the linkages might look like this:

INFO tempest.tests [req-a0df655b-18a2-4510-9e85-b9435dh8ye4 admin admin] 
Request ID Link: request.link.start 'req-a0df655b-18a2-4510-9e85-b9435dh8ye4'

INFO nova.utils [req-f0fb885b-18a2-4510-9e85-b9066b410ee4 admin admin] Request 
ID Link: request.link.image_download 'req-f0fb885b-18a2-4510-9e85-b9066b410ee4' 
-> Target='glance' TargetId=req-a1ac739c-c816-4f82-ad82-9a9b1a603f43

INFO tempest.tests [req-b0df857fb-18a2-4510-9e85-b9435dh8ye4 admin admin] 
Request ID Link: request.link.end 'req-b0df857fb-18a2-4510-9e85-b9435dh8ye4'

Concern:


As request_utils module is removed from oslo-incubator and this module is
also getting deprecated, I have following options to add it back to OpenStack.

Option 1: Add request_utils module in oslo.log (as it is related to logging
request_ids)
Option 2: Add request_utils module in oslo.utils
Option 3: Add link_request_ids method in utils.py of individual projects.
(this will cause code duplication)

Please let me know your thoughts about the same.

[1] 
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html
[2] 
http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-11-11-20.02.log.html
[3] 
http://docs.openstack.org/developer/oslo-incubator/api/openstack.common.request_utils.html

Thank You,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing 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] [tacker] Weekly meeting agenda - Mar 1, 2016

[Sridhar Ramaswamy]

Here is the agenda for this week's weekly meeting,

https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Mar_1.2C_2016

1700 UTC Tuesday
#openstack-meeting-4

* Announcements
* TOSCA parser integration
** Basic parser integration
** Auto Resource Creation
** Enhanced VNF placement
* Mitaka fit and finish - RFEs and Bugs
* Open Discussion
__
OpenStack Development Mailing 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] [ceilometer] Unable to get ceilometer events for instances running for demo project

[Umar Yousaf]

I have a single node configuration for devstack liberty working and I want
to record all the *ceilometer events* like compute.instance.start,
compute.instance.end, compute.instance.update etc occurred recently.
I am unable to get any event occurred for instances running for demo
project i.e when I try *ceilometer event-list* I end up with an empty list
but I could fortunately get all the necessary events occurred for instances
running for admin project/tenant with the same command.
In addition to this I want to get these through python client so if someone
could provide me with the equivalent python call, that would be more than
handy.
Thanks in advance :)
Regard,
Umar
__
OpenStack Development Mailing 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][ml2][Manila] API to query segments used during port binding

[Kevin Benton]

>This seems gross and backwards. It makes sense as a short term hack but
given that we have time to design this correctly I'd prefer to get this
information in a more straighforward way.

Well it depends on what is happening here. If Manilla is wiring up a
specific VLAN for a port, that makes it part of the port binding process,
in which case it should be an ML2 driver. Can you provide some more details
about what Manilla is doing with this info?

On Mon, Feb 29, 2016 at 5:29 PM, Ben Swartzlander 
wrote:

> On 02/29/2016 04:38 PM, Kevin Benton wrote:
>
>> You're correct. Right now there is no way via the HTTP API to find which
>> segments a port is bound to.
>> This is something we can certainly consider adding, but it will need an
>> RFE so it wouldn't land until Newton at the earliest.
>>
>
> I believe Newton is the target for this work. This is feature freeze week
> after all.
>
> Have you considered writing an ML2 driver that just notifies Manilla of
>> the port's segment info? All of this information is available to ML2
>> drivers in the PortContext object that is passed to them.
>>
>
> This seems gross and backwards. It makes sense as a short term hack but
> given that we have time to design this correctly I'd prefer to get this
> information in a more straighforward way.
>
> -Ben Swartzlander
>
>
> On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka > > wrote:
>>
>> Fixed neutron tag in the subject.
>>
>> Marc > wrote:
>>
>> Hi Neutron team,
>>
>> I am currently working on a feature for hierarchical port
>> binding support in
>> Manila [1] [2]. Just to give some context: In the current
>> implementation Manila
>> creates a neutron port but let it unbound (state DOWN).
>> Therefore Manila uses
>> the port create only retrieve an IP address and segmentation ID
>> (some drivers
>> only support VLAN here).
>>
>> My idea is to change this behavior and do an actual port binding
>> action so that
>> the configuration of VLAN isn’t a manual job any longer. And
>> that multi-segment
>> and HPB is supported on the long-run.
>>
>> My current issue is: How can Manila retrieve the segment
>> information for a
>> bound port? Manila only is interested in the last (bottom)
>> segmentation ID
>> since I assume the storage is connected to a ToR switch.
>>
>> Database-wise it’s possible to query it using
>> ml2_port_binding_levels table.
>> But AFAIK there is no API to query this. The only information
>> that is exposed
>> are all segments of a network. But this is not sufficient to
>> identify which
>> segments actually used for a port binding.
>>
>> Regards
>> Marc
>> SAP SE
>>
>> [1]:
>>
>> https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support
>> [2]: https://review.openstack.org/#/c/277731/
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <
>> http://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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

We have weekly Nova API meeting today. The meeting is being held Tuesday
UTC1200.

The proposed agenda and meeting details are here:

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

Please feel free to add items to the agenda.

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

Re: [openstack-dev] [Zaqar] Nominating Eva Balycheva for Zaqar core

[Eva Balycheva]

Thank you, it's a great honor for me to become core reviewer!
And responsibility...

Don't forget also these areas:

5. Zaqar server (most of my patches are for the server)
6. Contributor docs
7. Bug reporting (here I'm really effective)

On 03/01/2016 03:47 AM, Fei Long Wang wrote:

Hi all,

I would like to propose adding Eva Balycheva(Eva-i) for the Zaqar core
team. Eva has been an awesome contributor since joining the Zaqar team.
She is currently the most active non-core reviewer on Zaqar projects for
the last 90 days[1]. During this time, she's been contributing to many
different areas:

1. Websocket binary support
2. Zaqar Configuration Reference docs
3. Zaqar client
4. Zaqar benchmarking

Eva has got an good eye for review and contributed a lot of wonderful
patches[2]. I think she would make an excellent addition to the team. If
no one objects, I'll proceed and add her in a week from now.

[1] http://stackalytics.com/report/contribution/zaqar-group/90
[2]
https://review.openstack.org/#/q/owner:ubershy%2540gmail.com+status:merged



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

Re: [openstack-dev] [tricircle] playing tricircle with devstack under two-region configuration

[Vega Cai]

Hi, All,

Let's move the discussion to #openstack-tricircle in IRC.

BR
Zhiyuan

On 1 March 2016 at 11:07, Yipei Niu  wrote:

> Hi, all,
>
> The bug of deploying devstack with two-node configuration is already
> fixed. According to the official document, I have already installed
> devstack in two nodes successfully.
>
> Moreover, I am still trying to play tricircle in two nodes. When
> installing tricircle to node1, I still encounter the same error as before.
> The link is http://paste.openstack.org/show/488682/.
>
> Best regards,
> Yipei
>
> On Tue, Mar 1, 2016 at 10:56 AM, joehuang  wrote:
>
>> Hi, Yipei,
>>
>>
>>
>> The issue is that the OS_REGION_NAME should be “Pod2” for the Node2 for
>> Nova,Cinder, Neutron endpoint registration in KeyStone, but when creating
>> endpoint in Keystone, devstack will use command like “openstack endpoint
>> create” to access KeyStone, the OS_REGION_NAME should be the region name
>> where the KeyStone located, in two-nodes installation, it should be
>> “RegionOne” for the command itself.
>>
>>
>>
>> So it can be fixed by adding one more configurable global variable to
>> separate KeyStone region name and other services(Nova,Cinder,Neutron)
>> region name.
>>
>>
>>
>> Best Regards
>>
>> Chaoyi Huang ( Joe Huang )
>>
>>
>>
>> *From:* Yipei Niu [mailto:newy...@gmail.com]
>> *Sent:* Monday, February 29, 2016 10:02 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Cc:* Vega Cai; joehuang; 时鹏飞
>> *Subject:* Re: [tricircle] playing tricircle with devstack under
>> two-region configuration
>>
>>
>>
>> Hi Pengfei,
>>
>>
>>
>> I also encounter the same error when installing devstack on node2. I
>> insert a command "export OS_REGION_NAME=Pod2" in line 1262 in stack.sh and
>> it works. However, I am not sure whether it is correct. I am trying to
>> verify it. Recently, I try to re-install devstack on node1, but I encounter
>> some errors. The link is http://paste.openstack.org/show/488005/. Do you
>> have any suggestion about it?
>>
>>
>>
>> To Joe and Zhiyuan, could you please give me some advice about how to
>> solve it?
>>
>>
>>
>> Best regards,
>>
>> Yipei
>>
>>
>>
>> On Wed, Feb 24, 2016 at 9:29 AM, Yipei Niu  wrote:
>>
>> Hi Joe and Zhiyuan,
>>
>>
>>
>> My VM has recovered. When I re-install devstack in node1, I encounter the
>> following errors.
>>
>>
>>
>> The info in stack.sh.log is as follows:
>>
>>
>>
>> 2016-02-23 11:18:27.238 | Error: Service n-sch is not running
>>
>> 2016-02-23 11:18:27.238 | +
>> /home/stack/devstack/functions-common:service_check:L1625:   '[' -n
>> /opt/stack/status/stack/n-sch.failure ']'
>>
>> 2016-02-23 11:18:27.238 | +
>> /home/stack/devstack/functions-common:service_check:L1626:   die 1626 'More
>> details about the above errors can be found with screen, with
>> ./rejoin-stack.sh'
>>
>> 2016-02-23 11:18:27.238 | +
>> /home/stack/devstack/functions-common:die:L186:   local exitcode=0
>>
>> 2016-02-23 11:18:27.239 | [Call Trace]
>>
>> 2016-02-23 11:18:27.239 | ./stack.sh:1354:service_check
>>
>> 2016-02-23 11:18:27.239 | /home/stack/devstack/functions-common:1626:die
>>
>> 2016-02-23 11:18:27.261 | [ERROR]
>> /home/stack/devstack/functions-common:1626 More details about the above
>> errors can be found with screen, with ./rejoin-stack.sh
>>
>> 2016-02-23 11:18:28.271 | Error on exit
>>
>> 2016-02-23 11:18:28.953 | df: '/run/user/112/gvfs': Permission denied
>>
>>
>>
>> The info in n-sch.log is as follows:
>>
>>
>>
>> stack@nyp-VirtualBox:~/devstack$ /usr/local/bin/nova-scheduler
>> --config-file /et ^Mc/nova/nova.conf & echo $!
>> >/opt/stack/status/stack/n-sch.pid; fg || echo "n-sch ^M failed to start" |
>> tee "/opt/stack/status/stack/n-sch.failure"
>>
>> [1] 29467
>>
>> /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
>>
>> 2016-02-23 19:13:00.050 ^[[00;32mDEBUG oslo_db.api [^[[00;36m-^[[00;32m]
>> ^[[01;35m^[[00;32mLoading backend 'sqlalchemy' from
>> 'nova.db.sqlalchemy.api'^[[00m ^[[00;33mfrom (pid=29467) _load_backend
>> /usr/local/lib/python2.7/dist-packages/oslo_db/api.py:238^[[00m
>>
>> 2016-02-23 19:13:00.300 ^[[01;33mWARNING
>> oslo_reports.guru_meditation_report [^[[00;36m-^[[01;33m]
>> ^[[01;35m^[[01;33mGuru mediation now registers SIGUSR1 and SIGUSR2 by
>> default for backward compatibility. SIGUSR1 will no longer be registered in
>> a future release, so please use SIGUSR2 to generate reports.^[[00m
>>
>> 2016-02-23 19:13:00.304 ^[[01;31mCRITICAL nova [^[[00;36m-^[[01;31m]
>> ^[[01;35m^[[01;31mValueError: Empty module name
>>
>> ^[[00m
>>
>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mTraceback
>> (most recent call last):
>>
>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>> "/usr/local/bin/nova-scheduler", line 10, in 
>>
>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>>  sys.exit(main())
>>
>> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
>> 

[openstack-dev] [cross-project] Meeting SKIPPED, Tue March 1st, 21:00 UTC

[Mike Perez]

Hi all!

We will be skipping the cross-project meeting since I have not been able to
confirm with the owners of the specs we would've discussed will be available
for the meeting:

* Event message format [1]
* Instance auto evacuation [2]

We will try again next week!

Also cross-project spec liaisons, take note that there is a separate meeting
taking place for cross-project quotas [3].

[1] - https://review.openstack.org/#/c/231382/
[2] - https://review.openstack.org/#/c/257809/
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/087684.html

-- 
Mike Perez

__
OpenStack Development Mailing 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] [Zaqar] Nominating Eva Balycheva for Zaqar core

[hao wang]

Very glad to +1 for Eva, she is a very good reviewer and coder!

2016-03-01 11:00 GMT+08:00 Victoria Martínez de la Cruz
:
> A huge +1 for this proposal.
>
> Eva has joined as an Outreachy intern for this round and she impacted the
> Zaqar project in a truly positive way.
>
> Thanks for all your contributions Eva, you totally deserve this.
>
> 2016-02-29 21:47 GMT-03:00 Fei Long Wang :
>>
>> Hi all,
>>
>> I would like to propose adding Eva Balycheva(Eva-i) for the Zaqar core
>> team. Eva has been an awesome contributor since joining the Zaqar team.
>> She is currently the most active non-core reviewer on Zaqar projects for
>> the last 90 days[1]. During this time, she's been contributing to many
>> different areas:
>>
>> 1. Websocket binary support
>> 2. Zaqar Configuration Reference docs
>> 3. Zaqar client
>> 4. Zaqar benchmarking
>>
>> Eva has got an good eye for review and contributed a lot of wonderful
>> patches[2]. I think she would make an excellent addition to the team. If
>> no one objects, I'll proceed and add her in a week from now.
>>
>> [1] http://stackalytics.com/report/contribution/zaqar-group/90
>> [2]
>> https://review.openstack.org/#/q/owner:ubershy%2540gmail.com+status:merged
>>
>> --
>> Cheers & Best regards,
>> Fei Long Wang (王飞龙)
>> --
>> Senior Cloud Software Engineer
>> Tel: +64-48032246
>> Email: flw...@catalyst.net.nz
>> Catalyst IT Limited
>> Level 6, Catalyst House, 150 Willis Street, Wellington
>> --
>>
>>
>> __
>> OpenStack Development Mailing 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] [tricircle] playing tricircle with devstack under two-region configuration

[Yipei Niu]

Hi, all,

The bug of deploying devstack with two-node configuration is already fixed.
According to the official document, I have already installed devstack in
two nodes successfully.

Moreover, I am still trying to play tricircle in two nodes. When installing
tricircle to node1, I still encounter the same error as before. The link is
http://paste.openstack.org/show/488682/.

Best regards,
Yipei

On Tue, Mar 1, 2016 at 10:56 AM, joehuang  wrote:

> Hi, Yipei,
>
>
>
> The issue is that the OS_REGION_NAME should be “Pod2” for the Node2 for
> Nova,Cinder, Neutron endpoint registration in KeyStone, but when creating
> endpoint in Keystone, devstack will use command like “openstack endpoint
> create” to access KeyStone, the OS_REGION_NAME should be the region name
> where the KeyStone located, in two-nodes installation, it should be
> “RegionOne” for the command itself.
>
>
>
> So it can be fixed by adding one more configurable global variable to
> separate KeyStone region name and other services(Nova,Cinder,Neutron)
> region name.
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
>
> *From:* Yipei Niu [mailto:newy...@gmail.com]
> *Sent:* Monday, February 29, 2016 10:02 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* Vega Cai; joehuang; 时鹏飞
> *Subject:* Re: [tricircle] playing tricircle with devstack under
> two-region configuration
>
>
>
> Hi Pengfei,
>
>
>
> I also encounter the same error when installing devstack on node2. I
> insert a command "export OS_REGION_NAME=Pod2" in line 1262 in stack.sh and
> it works. However, I am not sure whether it is correct. I am trying to
> verify it. Recently, I try to re-install devstack on node1, but I encounter
> some errors. The link is http://paste.openstack.org/show/488005/. Do you
> have any suggestion about it?
>
>
>
> To Joe and Zhiyuan, could you please give me some advice about how to
> solve it?
>
>
>
> Best regards,
>
> Yipei
>
>
>
> On Wed, Feb 24, 2016 at 9:29 AM, Yipei Niu  wrote:
>
> Hi Joe and Zhiyuan,
>
>
>
> My VM has recovered. When I re-install devstack in node1, I encounter the
> following errors.
>
>
>
> The info in stack.sh.log is as follows:
>
>
>
> 2016-02-23 11:18:27.238 | Error: Service n-sch is not running
>
> 2016-02-23 11:18:27.238 | +
> /home/stack/devstack/functions-common:service_check:L1625:   '[' -n
> /opt/stack/status/stack/n-sch.failure ']'
>
> 2016-02-23 11:18:27.238 | +
> /home/stack/devstack/functions-common:service_check:L1626:   die 1626 'More
> details about the above errors can be found with screen, with
> ./rejoin-stack.sh'
>
> 2016-02-23 11:18:27.238 | +
> /home/stack/devstack/functions-common:die:L186:   local exitcode=0
>
> 2016-02-23 11:18:27.239 | [Call Trace]
>
> 2016-02-23 11:18:27.239 | ./stack.sh:1354:service_check
>
> 2016-02-23 11:18:27.239 | /home/stack/devstack/functions-common:1626:die
>
> 2016-02-23 11:18:27.261 | [ERROR]
> /home/stack/devstack/functions-common:1626 More details about the above
> errors can be found with screen, with ./rejoin-stack.sh
>
> 2016-02-23 11:18:28.271 | Error on exit
>
> 2016-02-23 11:18:28.953 | df: '/run/user/112/gvfs': Permission denied
>
>
>
> The info in n-sch.log is as follows:
>
>
>
> stack@nyp-VirtualBox:~/devstack$ /usr/local/bin/nova-scheduler
> --config-file /et ^Mc/nova/nova.conf & echo $!
> >/opt/stack/status/stack/n-sch.pid; fg || echo "n-sch ^M failed to start" |
> tee "/opt/stack/status/stack/n-sch.failure"
>
> [1] 29467
>
> /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
>
> 2016-02-23 19:13:00.050 ^[[00;32mDEBUG oslo_db.api [^[[00;36m-^[[00;32m]
> ^[[01;35m^[[00;32mLoading backend 'sqlalchemy' from
> 'nova.db.sqlalchemy.api'^[[00m ^[[00;33mfrom (pid=29467) _load_backend
> /usr/local/lib/python2.7/dist-packages/oslo_db/api.py:238^[[00m
>
> 2016-02-23 19:13:00.300 ^[[01;33mWARNING
> oslo_reports.guru_meditation_report [^[[00;36m-^[[01;33m]
> ^[[01;35m^[[01;33mGuru mediation now registers SIGUSR1 and SIGUSR2 by
> default for backward compatibility. SIGUSR1 will no longer be registered in
> a future release, so please use SIGUSR2 to generate reports.^[[00m
>
> 2016-02-23 19:13:00.304 ^[[01;31mCRITICAL nova [^[[00;36m-^[[01;31m]
> ^[[01;35m^[[01;31mValueError: Empty module name
>
> ^[[00m
>
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mTraceback (most
> recent call last):
>
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/usr/local/bin/nova-scheduler", line 10, in 
>
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>  sys.exit(main())
>
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/opt/stack/nova/nova/cmd/scheduler.py", line 43, in main
>
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
>  topic=CONF.scheduler_topic)
>
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File
> "/opt/stack/nova/nova/service.py", line 281, in create
>
> ^[[01;31m2016-02-23 19:13:00.304 TRACE nova 

Re: [openstack-dev] [Zaqar] Nominating Eva Balycheva for Zaqar core

[Victoria Martínez de la Cruz]

A huge +1 for this proposal.

Eva has joined as an Outreachy intern for this round and she impacted the
Zaqar project in a truly positive way.

Thanks for all your contributions Eva, you totally deserve this.

2016-02-29 21:47 GMT-03:00 Fei Long Wang :

> Hi all,
>
> I would like to propose adding Eva Balycheva(Eva-i) for the Zaqar core
> team. Eva has been an awesome contributor since joining the Zaqar team.
> She is currently the most active non-core reviewer on Zaqar projects for
> the last 90 days[1]. During this time, she's been contributing to many
> different areas:
>
> 1. Websocket binary support
> 2. Zaqar Configuration Reference docs
> 3. Zaqar client
> 4. Zaqar benchmarking
>
> Eva has got an good eye for review and contributed a lot of wonderful
> patches[2]. I think she would make an excellent addition to the team. If
> no one objects, I'll proceed and add her in a week from now.
>
> [1] http://stackalytics.com/report/contribution/zaqar-group/90
> [2]
> https://review.openstack.org/#/q/owner:ubershy%2540gmail.com+status:merged
>
> --
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --
>
>
> __
> OpenStack Development Mailing 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] [tricircle] playing tricircle with devstack under two-region configuration

[joehuang]

Hi, Yipei,

The issue is that the OS_REGION_NAME should be “Pod2” for the Node2 for 
Nova,Cinder, Neutron endpoint registration in KeyStone, but when creating 
endpoint in Keystone, devstack will use command like “openstack endpoint 
create” to access KeyStone, the OS_REGION_NAME should be the region name where 
the KeyStone located, in two-nodes installation, it should be “RegionOne” for 
the command itself.

So it can be fixed by adding one more configurable global variable to separate 
KeyStone region name and other services(Nova,Cinder,Neutron) region name.

Best Regards
Chaoyi Huang ( Joe Huang )

From: Yipei Niu [mailto:newy...@gmail.com]
Sent: Monday, February 29, 2016 10:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Vega Cai; joehuang; 时鹏飞
Subject: Re: [tricircle] playing tricircle with devstack under two-region 
configuration

Hi Pengfei,

I also encounter the same error when installing devstack on node2. I insert a 
command "export OS_REGION_NAME=Pod2" in line 1262 in stack.sh and it works. 
However, I am not sure whether it is correct. I am trying to verify it. 
Recently, I try to re-install devstack on node1, but I encounter some errors. 
The link is http://paste.openstack.org/show/488005/. Do you have any suggestion 
about it?

To Joe and Zhiyuan, could you please give me some advice about how to solve it?

Best regards,
Yipei

On Wed, Feb 24, 2016 at 9:29 AM, Yipei Niu 
> wrote:
Hi Joe and Zhiyuan,

My VM has recovered. When I re-install devstack in node1, I encounter the 
following errors.

The info in stack.sh.log is as follows:

2016-02-23 11:18:27.238 | Error: Service n-sch is not running
2016-02-23 11:18:27.238 | + 
/home/stack/devstack/functions-common:service_check:L1625:   '[' -n 
/opt/stack/status/stack/n-sch.failure ']'
2016-02-23 11:18:27.238 | + 
/home/stack/devstack/functions-common:service_check:L1626:   die 1626 'More 
details about the above errors can be found with screen, with ./rejoin-stack.sh'
2016-02-23 11:18:27.238 | + /home/stack/devstack/functions-common:die:L186:   
local exitcode=0
2016-02-23 11:18:27.239 | [Call Trace]
2016-02-23 11:18:27.239 | ./stack.sh:1354:service_check
2016-02-23 11:18:27.239 | /home/stack/devstack/functions-common:1626:die
2016-02-23 11:18:27.261 | [ERROR] /home/stack/devstack/functions-common:1626 
More details about the above errors can be found with screen, with 
./rejoin-stack.sh
2016-02-23 11:18:28.271 | Error on exit
2016-02-23 11:18:28.953 | df: '/run/user/112/gvfs': Permission denied

The info in n-sch.log is as follows:

stack@nyp-VirtualBox:~/devstack$ /usr/local/bin/nova-scheduler --config-file 
/et ^Mc/nova/nova.conf & echo $! >/opt/stack/status/stack/n-sch.pid; fg || echo 
"n-sch ^M failed to start" | tee "/opt/stack/status/stack/n-sch.failure"
[1] 29467
/usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf
2016-02-23 19:13:00.050 ^[[00;32mDEBUG oslo_db.api [^[[00;36m-^[[00;32m] 
^[[01;35m^[[00;32mLoading backend 'sqlalchemy' from 
'nova.db.sqlalchemy.api'^[[00m ^[[00;33mfrom (pid=29467) _load_backend 
/usr/local/lib/python2.7/dist-packages/oslo_db/api.py:238^[[00m
2016-02-23 19:13:00.300 ^[[01;33mWARNING oslo_reports.guru_meditation_report 
[^[[00;36m-^[[01;33m] ^[[01;35m^[[01;33mGuru mediation now registers SIGUSR1 
and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be 
registered in a future release, so please use SIGUSR2 to generate reports.^[[00m
2016-02-23 19:13:00.304 ^[[01;31mCRITICAL nova [^[[00;36m-^[[01;31m] 
^[[01;35m^[[01;31mValueError: Empty module name
^[[00m
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mTraceback (most 
recent call last):
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
"/usr/local/bin/nova-scheduler", line 10, in 
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00msys.exit(main())
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
"/opt/stack/nova/nova/cmd/scheduler.py", line 43, in main
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
topic=CONF.scheduler_topic)
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
"/opt/stack/nova/nova/service.py", line 281, in create
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m
db_allowed=db_allowed)
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
"/opt/stack/nova/nova/service.py", line 167, in __init__
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mself.manager = 
manager_class(host=self.host, *args, **kwargs)
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
"/opt/stack/nova/nova/scheduler/manager.py", line 49, in __init__
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00mself.driver = 
importutils.import_object(scheduler_driver)
^[[01;31m2016-02-23 19:13:00.304 TRACE nova ^[[01;35m^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 44, in 

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

[王华]

I think users need the support for multiple OS choices. Users may want to
modify the OS by themselves to meet the requirement of their business. If
Magnum only supports a single OS distro, we should have a  convenient way
to change one OS distro to another. But the OSes are so different, the work
is difficult. So if Magnum only supports a single OS distro, the users are
locked into one OS distro.

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

Re: [openstack-dev] [devstack] [neutron] How to ask for linuxbridge instead of openvswitch

[Anita Kuno]

On 02/29/2016 05:58 PM, Mike Spreitzer wrote:
> How would I modify the recipe at 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
>  
> to get linuxbridge instead of openvswitch?
> 
> Thanks,
> Mike
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

The source code is here:
http://git.openstack.org/cgit/openstack-dev/devstack/tree/doc/source/guides/neutron.rst#n11

The getting started guide for new developer's is here:
http://docs.openstack.org/infra/manual/developers.html#getting-started

Do speak up in any of the #openstack-neutron, #openstack-qa (they take
care of devstack) or #openstack-infra irc channels on freenode if you
have any questions.

Thank you for wanting to contribute to the docs,
Anita.

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

Re: [openstack-dev] [kolla] unblocking the gate

[Clark Boylan]

On Mon, Feb 29, 2016, at 01:38 PM, Sam Yaple wrote:
> On Mon, Feb 29, 2016 at 6:42 PM, Clark Boylan 
> wrote:
> 
> > On Mon, Feb 29, 2016, at 09:09 AM, Steven Dake (stdake) wrote:
> > >
> > >
> > > On 2/29/16, 12:26 AM, "Andreas Jaeger"  wrote:
> > > >This is not needed, the CI system always rebases if you run tests. To
> > > >get current tests, a simple "recheck" is enough.
> > > >
> > > >Also, we test in the gate before merging - again after rebasing to head.
> > > >That should take care of not merging anything broken. Running recheck
> > > >after a larger change will ensure that you have recent results.
> > >
> > > Andreas,
> > >
> > > Thanks for the recheck information.  I thought the gate ran against what
> > > it was submitted with as head.  We don't have any gate jobs at present
> > > (or
> > > many) they are mostly check jobs, so its pre-merge checking that we need
> > > folks to do.
> > >
> > To clarify the check pipeline changes are merged into their target
> > branches before testing and the gate pipeline changes are merged into
> > the forward looking state of the world that Zuul generates as part of
> > gate testing. This means you do not need to rebase and create new
> > patchsets to get updated test results, just recheck.
> >
> >
> Unfortunately we do not have voting gates in Kolla that do building and
> deploying. This will change soon, but that would be where the confusion
> in
> the thread is coming from I believe. Our only indication is a "Green"
> check
> job at this time. This is why Steven is asking for a rebase to make the
> check gates green before we merge new patches.

I understand the situation with check vs gate tests, but my previous
statement (below) still holds. All you need to do is recheck. You only
need a rebase if you have run into a merge conflict.

> 
> You should only need to rebase and create a new patchset if a merge
> > conflict exists.

Clark


__
OpenStack Development Mailing 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] [Fuel][Fuel-Library] Fuel CI issues

[Dmitry Borodaenko]

On Mon, Feb 29, 2016 at 01:19:29PM +0300, Vladimir Kuklin wrote:
> Thanks for bringing this up. Frankly, I think that we hurried a little bit
> by making our integration with upstream puppet manifests too continuous. I
> would suppose that we used a little bit different technique.

I don't think "hurried" is applicable here: the only way to become more
ready to track upstream than we already are is to *start* tracking
upstream. Postponing that leaves us in a Catch-22 situation where we
can't stay in sync with upstream because we're not continuously catching
up with upstream.

> First of all, we need to have a set of stable Fuel commits against which
> the changes to upstream manifests should be tested. Could you please
> elaborate on whether we are doing this already?

We are using the same known-good Fuel ISO for puppet-openstack and
fuel-library, so in that sense, yes, we are doing this already.

We use the HEAD of master branch of fuel-library in these tests, because
using the fuel-library commit from the known-good ISO would mean having
to update that ISO every time we merge a commit that brings fuel-library
up to date with recent changes in puppet-openstack.

> Secondly, we need to have FUEL CI working with a set of stable commits of
> puppet openstack manifests which passed those upstream tests as we should
> not have too much moving parts or we will get into situation similar to
> requirements.txt updates when we have pypi updated with new library, e.g.
> oslo-serialization.

That would lock us into that Catch-22 situation where we can't allow 
Fuel CI to vote on puppet-openstack commits because fuel-library is
always too far behind puppet-openstack for its votes to mean anything
useful.

We have to approach this from the opposite direction: make Fuel CI
stable and meaningful enough so that, 9 times out of 10, Fuel CI failure
indicates a real problem with the code, and the remaining cases can be
quickly unblocked by pushing a catch-up commit to fuel-library (ideally
with a Depends-On tag).

It is a matter of trust between projects: do we trust Puppet OpenStack
project to take Fuel's problems seriously and to avoid breaking our CI
more often than necessary? Can Puppet OpenStack project trust us with
the same? So far, our collaboration track record has been pretty good
bordering on examplary, and I think we should build on that and move 
forward instead of clinging to the old ways.

> In this case, we will be able to do proper testing against frozen code-base
> for each piece thus avoiding such issues while retaining fair amount of
> integration with upstream puppet manifests for OpenStack.

The problem with moving only one piece at a time is that you end up so
far behind that you're slowing everyone down. BKL and GIL are not the
only way to deal with concurrency, we can do better than that.

-- 
Dmitry Borodaenko


> On Fri, Feb 26, 2016 at 1:28 PM, Ivan Berezovskiy  > wrote:
> 
> > Hello, Fuelers!
> >
> > Yesterday we've faced an issue which came from puppet-neutron
> > module: LP #1549934 . Fix
> > was prepared very fast:
> > https://review.openstack.org/#/c/284882/ (thanks Sergey for this).
> > So, If CI is red on your patch please re-base it on top of master.
> >
> > Anyway, this issue affected a lot of patches and blocked some developers,
> > because BVT and neutron_smoke tests was also broken. We need to find
> > a way how to minimize risks and affection of such changes on fuel-library.
> > We have jobs which monitors upstream patches:
> > https://ci.fuel-infra.org/view/puppet-openstack/
> > Let's start to monitor those jobs on daily basis. We should have at least 1
> > (ideally 2 or more) engineers which are responsible for analysis of those
> > CI failures. If patch to puppet module is incorrect - we should review it
> > with explanation what is actually wrong. If patch is correct, but breaks
> > current Fuel CI, it means that problem is in our side and we should prepare
> > fuel-library adapt patch to fix the issue. Ideally, we should have an
> > ability
> > to test this fuel-library patch together with upstream one e.g. using
> > 'Depends on'
> > in commit message.
> >
> > Thoughts?
> >
> > --
> > Thanks, Ivan Berezovskiy
> > MOS Puppet Team Lead
> > at Mirantis 
> >
> > slack: iberezovskiy
> > skype: bouhforever
> > phone: + 7-960-343-42-46
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> 
> -- 
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> 

Re: [openstack-dev] [devstack] [neutron] How to ask for linuxbridge instead of openvswitch

[Brian Stajkowski]

http://docs.openstack.org/developer/devstack/guides/neutron.html#using-linux-bridge-instead-of-open-vswitch

Does this work for you?

--
Brian Stajkowski
Manager, Software Development - US
m: 702.575.7890
irc: ski
e: brian.stajkow...@rackspace.com

From: Mike Spreitzer >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, February 29, 2016 at 4:58 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [devstack] [neutron] How to ask for linuxbridge 
instead of openvswitch

How would I modify the recipe at 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interfaceto
 get linuxbridge instead of openvswitch?

Thanks,
Mike


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

[openstack-dev] Mitaka IP Availability [Urgent]

[Brian Stajkowski]

All,

We just need 1 more +2 and the workflow completed for ip availability to make 
it into Mitaka.  Is it possible we can get this reviewed and merged.  Any help 
is appreciated.

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

Thanks!
--
Brian Stajkowski
Manager, Software Development - US
m: 702.575.7890
irc: ski
e: brian.stajkow...@rackspace.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

[Ben Swartzlander]

On 02/29/2016 04:38 PM, Kevin Benton wrote:

You're correct. Right now there is no way via the HTTP API to find which
segments a port is bound to.
This is something we can certainly consider adding, but it will need an
RFE so it wouldn't land until Newton at the earliest.


I believe Newton is the target for this work. This is feature freeze 
week after all.



Have you considered writing an ML2 driver that just notifies Manilla of
the port's segment info? All of this information is available to ML2
drivers in the PortContext object that is passed to them.


This seems gross and backwards. It makes sense as a short term hack but 
given that we have time to design this correctly I'd prefer to get this 
information in a more straighforward way.


-Ben Swartzlander



On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka > wrote:

Fixed neutron tag in the subject.

Marc > wrote:

Hi Neutron team,

I am currently working on a feature for hierarchical port
binding support in
Manila [1] [2]. Just to give some context: In the current
implementation Manila
creates a neutron port but let it unbound (state DOWN).
Therefore Manila uses
the port create only retrieve an IP address and segmentation ID
(some drivers
only support VLAN here).

My idea is to change this behavior and do an actual port binding
action so that
the configuration of VLAN isn’t a manual job any longer. And
that multi-segment
and HPB is supported on the long-run.

My current issue is: How can Manila retrieve the segment
information for a
bound port? Manila only is interested in the last (bottom)
segmentation ID
since I assume the storage is connected to a ToR switch.

Database-wise it’s possible to query it using
ml2_port_binding_levels table.
But AFAIK there is no API to query this. The only information
that is exposed
are all segments of a network. But this is not sufficient to
identify which
segments actually used for a port binding.

Regards
Marc
SAP SE

[1]:
https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support
[2]: https://review.openstack.org/#/c/277731/

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

[yongli he]

Hi, Beliveau, Ludovic

currently the alias define as a multiple string option item. this make 
the code look this configure option is a array, but user define it 
multiple times instead of a array.

pci_alias_opt = cfg.MultiStrOpt

Yongli He


在 2015年10月27日 23:44, Beliveau, Ludovic 写道:

Hi,

I'm configuring multiple pci_alias like so:

pci_alias=[{"vendor_id":"8086", "product_id":"0443", "name":"a1"}, 
{"vendor_id":"8086", "product_id":"0443", "name":"a2"}]


But I'm getting the following error when booting an instance:
ERROR (BadRequest): Invalid PCI alias definition: [{u'vendor_id': 
u'8086', u'product_id': u'0443', u'name': u'a1'}, {u'vendor_id': 
u'8086', u'product_id': u'0443', u'name': u'a2'}] is not of type 
'object' Failed validating 'type' in schema: {'additionalProperties': 
False, 'properties': {'capability_type': {'enum': ['pci'], 'type': 
'string'}, 'device_type': {'enum': ['NIC', 'ACCEL', 'GPU'], 'type': 
'string'}, 'name': {'maxLength': 256, 'minLength': 1, 'type': 
'string'}, 'product_id': {'pattern': '^([\\da-fA-F]{4})$', 'type': 
'string'}, 'vendor_id': {'pattern': '^([\\da-fA-F]{4})$', 'type': 
'string'}}, 'required': ['name'], 'type': 'object'} On instance: 
[{u'name': u'a1', u'product_id': u'0443', u'vendor_id': u'8086'}, 
{u'name': u'a2', u'product_id': u'0443', u'vendor_id': u'8086'}] (HTTP 
400) (Request-ID: req-3fe994bc-6a99-4c0c-be98-1a22703c58ee)


Based on the code, the default value for the pci_alias is an array.  
So I'm expecting that defining multiple pci_alias withing an array 
would be supported.  Or am I missing something ?


The workaround to this issue would be to declare each pci_alias in a 
separate line in nova.conf:


pci_alias={"vendor_id":"8086", "product_id":"0443", "name":"a1"}
pci_alias={"vendor_id":"8086", "product_id":"0443", "name":"a2"}

This format is valid for a pci_passthrough_whitelist, I think for 
clarity and consistency they should align.


Furthermore, the nova puppet module 
(puppet/modules/nova/manifests/api.pp) is also expecting the pci_alias 
to be defined as a list.


Thanks,
/ludovic


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


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

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

[Madhusudhan Kandadai]

Okay, Figured out the issue.When debugging, I was trying to create lb and
barbican clients with different users. Thanks guys!

On Mon, Feb 29, 2016 at 2:07 PM, Phillip Toohill <
phillip.tooh...@rackspace.com> wrote:

> Is the create LB happening on a different user than the one that created
> the barbican container? Maybe im not looking at it right, but cant tell
> from this.
>
>
> Phillip V. Toohill III
> Software Developer
> phone: 210-312-4366
> mobile: 210-440-8374
>
>
>
> --
> *From:* Madhusudhan Kandadai 
> *Sent:* Monday, February 29, 2016 3:47 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container
> could not be found
>
> Is what I can see the error logs in barbican svc screen while I create TLS
> listener like this: http://paste.openstack.org/show/xVl9iuJtGW03fCGetDm3/
>
> 2016-02-29 13:42:55.222 INFO barbican.api.middleware.context
> [req-65fd0f08-4c1e-4b2f-9cbd-64f186365077 afaa5d797f3543369d05e370a543ef9d
> c141e106a7424d1a8316cf03a8c91e40] Processed request: 404 Not Found - POST
> http://192.168.109.129:9311/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/
> {address space usage: 220770304 bytes/210MB} {rss usage: 101371904
> bytes/96MB} [pid: 52558|app: 0|req: 75/75] 192.168.109.129 () {34 vars in
> 598 bytes} [Mon Feb 29 13:42:55 2016] POST
> /v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/ => generated
> 111 bytes in 214 msecs (HTTP/1.1 404) 4 headers in 179 bytes (1 switches on
> core 0)
> 2016-02-29 13:43:17.397 ERROR barbican.model.repositories
> [req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
> c141e106a7424d1a8316cf03a8c91e40] Not found for
> d96dccd5-0d39-4f67-ba3a-366a84cfd371
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories Traceback (most
> recent call last):
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories   File
> "/opt/stack/barbican/barbican/model/repositories.py", line 354, in get
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories entity =
> query.one()
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories   File
> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line
> 2699, in one
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories raise
> orm_exc.NoResultFound("No row was found for one()")
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories NoResultFound:
> No row was found for one()
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories
> 2016-02-29 13:43:17.398 ERROR barbican.api.controllers
> [req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
> c141e106a7424d1a8316cf03a8c91e40] Webob error seen
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers Traceback (most
> recent call last):
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 104, in
> handler
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 90, in
> enforcer
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 146, in
> content_types_enforcer
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/consumers.py", line 143, in
> on_post
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> controllers.containers.container_not_found()
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/containers.py", line 36, in
> container_not_found
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> pecan.abort(404, u._('Not Found. Sorry but your container is in '
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/usr/local/lib/python2.7/dist-packages/pecan/core.py", line 141, in abort
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers exec('raise
> webob_exception, None, traceback')
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/consumers.py", line 141, in
> on_post
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> external_project_id)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/model/repositories.py", line 360, in get
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> _raise_entity_not_found(self._do_entity_name(), entity_id)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> 

[openstack-dev] [Zaqar] Nominating Eva Balycheva for Zaqar core

[Fei Long Wang]

Hi all,

I would like to propose adding Eva Balycheva(Eva-i) for the Zaqar core
team. Eva has been an awesome contributor since joining the Zaqar team.
She is currently the most active non-core reviewer on Zaqar projects for
the last 90 days[1]. During this time, she's been contributing to many
different areas:

1. Websocket binary support
2. Zaqar Configuration Reference docs
3. Zaqar client
4. Zaqar benchmarking 

Eva has got an good eye for review and contributed a lot of wonderful
patches[2]. I think she would make an excellent addition to the team. If
no one objects, I'll proceed and add her in a week from now.

[1] http://stackalytics.com/report/contribution/zaqar-group/90
[2]
https://review.openstack.org/#/q/owner:ubershy%2540gmail.com+status:merged

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


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

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

[Bharath M]

As Adam stated, it could be any of those reasons. Mainly look for the
credentials defined under [service_auth] section of lbaas conf file. Most
importantly the credentials, tenant (or project) name should be the same as
the user that created the container. This is assuming you aren't using
ACLs'.

On Mon, Feb 29, 2016 at 2:07 PM, Phillip Toohill <
phillip.tooh...@rackspace.com> wrote:

> Is the create LB happening on a different user than the one that created
> the barbican container? Maybe im not looking at it right, but cant tell
> from this.
>
>
> Phillip V. Toohill III
> Software Developer
> phone: 210-312-4366
> mobile: 210-440-8374
>
>
>
> --
> *From:* Madhusudhan Kandadai 
> *Sent:* Monday, February 29, 2016 3:47 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container
> could not be found
>
> Is what I can see the error logs in barbican svc screen while I create TLS
> listener like this: http://paste.openstack.org/show/xVl9iuJtGW03fCGetDm3/
>
> 2016-02-29 13:42:55.222 INFO barbican.api.middleware.context
> [req-65fd0f08-4c1e-4b2f-9cbd-64f186365077 afaa5d797f3543369d05e370a543ef9d
> c141e106a7424d1a8316cf03a8c91e40] Processed request: 404 Not Found - POST
> http://192.168.109.129:9311/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/
> {address space usage: 220770304 bytes/210MB} {rss usage: 101371904
> bytes/96MB} [pid: 52558|app: 0|req: 75/75] 192.168.109.129 () {34 vars in
> 598 bytes} [Mon Feb 29 13:42:55 2016] POST
> /v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/ => generated
> 111 bytes in 214 msecs (HTTP/1.1 404) 4 headers in 179 bytes (1 switches on
> core 0)
> 2016-02-29 13:43:17.397 ERROR barbican.model.repositories
> [req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
> c141e106a7424d1a8316cf03a8c91e40] Not found for
> d96dccd5-0d39-4f67-ba3a-366a84cfd371
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories Traceback (most
> recent call last):
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories   File
> "/opt/stack/barbican/barbican/model/repositories.py", line 354, in get
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories entity =
> query.one()
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories   File
> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line
> 2699, in one
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories raise
> orm_exc.NoResultFound("No row was found for one()")
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories NoResultFound:
> No row was found for one()
> 2016-02-29 13:43:17.397 TRACE barbican.model.repositories
> 2016-02-29 13:43:17.398 ERROR barbican.api.controllers
> [req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
> c141e106a7424d1a8316cf03a8c91e40] Webob error seen
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers Traceback (most
> recent call last):
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 104, in
> handler
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 90, in
> enforcer
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/__init__.py", line 146, in
> content_types_enforcer
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
> *args, **kwargs)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/consumers.py", line 143, in
> on_post
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> controllers.containers.container_not_found()
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/containers.py", line 36, in
> container_not_found
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> pecan.abort(404, u._('Not Found. Sorry but your container is in '
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/usr/local/lib/python2.7/dist-packages/pecan/core.py", line 141, in abort
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers exec('raise
> webob_exception, None, traceback')
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/api/controllers/consumers.py", line 141, in
> on_post
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers
> external_project_id)
> 2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
> "/opt/stack/barbican/barbican/model/repositories.py", line 360, in get
> 2016-02-29 13:43:17.398 TRACE 

[openstack-dev] Limits on volume read throughput?

[Preston L. Bannister]

I have need to benchmark volume-read performance of an application running
in an instance, assuming extremely fast storage.

To simulate fast storage, I have an AIO install of OpenStack, with local
flash disks. Cinder LVM volumes are striped across three flash drives (what
I have in the present setup).

Since I am only interested in sequential-read performance, the "dd" utility
is sufficient as a measure.

Running "dd" in the physical host against the Cinder-allocated volumes nets
~1.2GB/s (roughly in line with expectations for the striped flash volume).

Running "dd" in an instance against the same volume (now attached to the
instance) got ~300MB/s, which was pathetic. (I was expecting 80-90% of the
raw host volume numbers, or better.) Upping read-ahead in the instance via
"hdparm" boosted throughput to ~450MB/s. Much better, but still sad.

In the second measure the volume data passes through iSCSI and then the
QEMU hypervisor. I expected to lose *some* performance, but not more than
half!

Note that as this is an all-in-one OpenStack node, iSCSI is strictly local
and not crossing a network. (I did not want network latency or throughput
to be a concern with this first measure.)

I do not see any prior mention of performance of this sort on the web or in
the mailing list. Possible I missed something.

What sort of numbers are you seeing out of high performance storage?

Is the *huge* drop in read-rate within an instance something others have
seen?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

We are happy to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 22.02.2016):
- Ironic: 162 bugs (+6) + 178 wishlist items (+3). 16 new (+2), 123 in
progress (+5), 0 critical, 22 high (+3) and 12 incomplete (+1)
- Inspector: 10 bugs + 15 wishlist items. 0 new, 6 in progress (-1), 0
critical, 2 high (-1) and 0 incomplete
- Nova bugs with Ironic tag: 16. 0 new, 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- refactoring of the driver patch in progress:
- https://review.openstack.org/285850
- https://review.openstack.org/285851
- https://review.openstack.org/285852
- need reviews on this :)

Manual cleaning (rloo)
==
- done. sort of. GET clean steps API is not done; deferring to Newton.

RAID (lucasagomes)
==
- https://review.openstack.org/226234 CLI
- https://review.openstack.org/226330 documentation

Parallel tasks with futurist (dtantsur)
===
- MERGED \o/
- similar work is ongoing for inspector: https://review.openstack.org/286022

Node filter API and claims endpoint (jroll, devananda, lucasagomes)
===
- no update; deprioritized in favor of neutron work, manual cleaning

Nova Liaisons (jlvillal & mrda)
===
- Did a quick check. No new activity this week as far as bug activity.

Testing/Quality (jlvillal/lekha/krtaylor)
=
- Progress was made on grenade. jlvillal was able to get it locally to run
the devstack portion successfully on the stable/liberty branch
- There is a regression issue in stable/liberty:
https://bugs.launchpad.net/bugs/1549095  jlvillal will likely propose a
work-around patch for the issue.
- Have not come to a solution on how to make Grenade only test
baremetal things. Solution that is acceptable to be pushed upstream. Having
working local solution (jlvillal)
- Verifying M2 milestone for CI test systems - first pass complete, have a
few questions on some systems
- https://etherpad.openstack.org/p/IronicCI

Inspector (dtansur)
===
- Released ironic-inspector 2.2.4 for liberty with 2 bug fixes
- feature reviews wanted: https://review.openstack.org/#/c/267637/ run
introspection on previously stored data

Drivers:

 AMT (lintan)
-
- Migrating to Ironic-staging-driver project, there will be no CI for AMT
driver :(

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
OpenStack Development Mailing 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] DocImpact flag: a kind reminder

[Hirofumi Ichihara]

On 2016/03/01 9:00, Armando M. wrote:



On 29 February 2016 at 15:34, Hirofumi Ichihara 
> wrote:


Hi Armando,

I didn't know and I have such patch now.
Thank you for your message.

I have seen that neutron spec has the flag in the Commit Message.
In such case, we don't need to add the flag into the
implementation patch, do we?


I would not personally add a DocImpact on a spec patch.

I agree with you.



Thanks,
Hirofumi


On 2016/03/01 7:18, Armando M. wrote:

Hi Neutrinos,

Please remember that what you decorate a commit message with
DocImpact, this must be followed by a brief description of the
documentation impact [1]. Also, please be aware that currently,
as soon as the patch merges, a bug report is filed against the
Launchpad project of the targeted repo. This is tagged with 'doc'
and '' [2].

So, if you have a train of patches affecting the same feature
(client side, server side, *-aas projects etc), be mindful to
where you put the tag and avoid adding DocImpact to more than one
commit message, unless the documentation target is indeed meant
to be separate.

Cheers,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080294.html
[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc


__
OpenStack Development Mailing 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] [Neutron] DocImpact flag: a kind reminder

[Armando M.]

On 29 February 2016 at 15:34, Hirofumi Ichihara <
ichihara.hirof...@lab.ntt.co.jp> wrote:

> Hi Armando,
>
> I didn't know and I have such patch now.
> Thank you for your message.
>
> I have seen that neutron spec has the flag in the Commit Message.
> In such case, we don't need to add the flag into the implementation patch,
> do we?
>

I would not personally add a DocImpact on a spec patch.


>
> Thanks,
> Hirofumi
>
>
> On 2016/03/01 7:18, Armando M. wrote:
>
> Hi Neutrinos,
>
> Please remember that what you decorate a commit message with DocImpact,
> this must be followed by a brief description of the documentation impact
> [1]. Also, please be aware that currently, as soon as the patch merges, a
> bug report is filed against the Launchpad project of the targeted repo.
> This is tagged with 'doc' and '' [2].
>
> So, if you have a train of patches affecting the same feature (client
> side, server side, *-aas projects etc), be mindful to where you put the tag
> and avoid adding DocImpact to more than one commit message, unless the
> documentation target is indeed meant to be separate.
>
> Cheers,
> Armando
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080294.html
> [2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] DocImpact flag: a kind reminder

[Hirofumi Ichihara]

Hi Armando,

I didn't know and I have such patch now.
Thank you for your message.

I have seen that neutron spec has the flag in the Commit Message.
In such case, we don't need to add the flag into the implementation 
patch, do we?


Thanks,
Hirofumi

On 2016/03/01 7:18, Armando M. wrote:

Hi Neutrinos,

Please remember that what you decorate a commit message with 
DocImpact, this must be followed by a brief description of the 
documentation impact [1]. Also, please be aware that currently, as 
soon as the patch merges, a bug report is filed against the Launchpad 
project of the targeted repo. This is tagged with 'doc' and 
'' [2].


So, if you have a train of patches affecting the same feature (client 
side, server side, *-aas projects etc), be mindful to where you put 
the tag and avoid adding DocImpact to more than one commit message, 
unless the documentation target is indeed meant to be separate.


Cheers,
Armando

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080294.html

[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc


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


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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/29/2016 06:17 PM, Eoghan Glynn wrote:
> 
> 
> Current thinking would be to give preferential rates to access the main
> summit to people who are present to other events (like this new
> separated contributors-oriented event, or Ops midcycle(s)). That would
> allow for a wider definition of "active community member" and reduce
> gaming.
>

 I think reducing gaming is important. It is valuable to include those
 folks who wish to make a contribution to OpenStack, I have confidence
 the next iteration of entry structure will try to more accurately
 identify those folks who bring value to OpenStack.
>>>
>>> There have been a couple references to "gaming" on this thread, which
>>> seem to imply a certain degree of dishonesty, in the sense of bending
>>> the rules.
>>>
>>> Can anyone who has used the phrase clarify:
>>>
>>>  (a) what exactly they mean by gaming in this context
>>>
>>> and:
>>>
>>>  (b) why they think this is a clear & present problem demanding a
>>>  solution?
>>>
>>> For the record, landing a small number of patches per cycle and thus
>>> earning an ATC summit pass as a result is not, IMO at least, gaming.
>>>
>>> Instead, it's called *contributing*.
>>>
>>> (on a small scale, but contributing none-the-less).
>>>
>>> Cheers,
>>> Eoghan
>>
>> Sure I can tell you what I mean.
>>
>> In Vancouver I happened to be sitting behind someone who stated "I'm
>> just here for the buzz." Which is lovely for that person. The problem is
>> that the buzz that person is there for is partially created by me and I
>> create it and mean to offer it to people who will return it in kind, not
>> just soak it up and keep it to themselves.
>>
>> Now I have no way of knowing who this person is and how they arrived at
>> the event. But the numbers for people offering one patch to OpenStack
>> (the bar for a summit pass) is significantly higher than the curve of
>> people offering two, three or four patches to OpenStack (patches that
>> are accepted and merged). So some folks are doing the minimum to get a
>> summit pass rather than being part of the cohort that has their first
>> patch to OpenStack as a means of offering their second patch to OpenStack.
>>
>> I consider it an honour and a privilege that I get to work with so many
>> wonderful people everyday who are dedicated to making open source clouds
>> available for whoever would wish to have clouds. I'm more than a little
>> tired of having my energy drained by folks who enjoy feeding off of it
>> while making no effort to return beneficial energy in kind.
>>
>> So when I use the phrase gaming, this is the dynamic to which I refer.
> 
> Thanks for the response.
> 
> I don't know if drive-by attendance at design summit sessions by under-
> qualified or uninformed summiteers is encouraged by the availability of
> ATC passes. But as long as those individuals aren't actively derailing
> the conversation in sessions, I wouldn't consider their buzz soakage as
> a major issue TBH. 
> 
> In any case, I would say that just meeting the bar for an ATC summit pass
> (by landing the required number of patches) is not bending the rules or
> misrepresenting in any way.
> 
> Even if specifically motivated by the ATC pass (as opposed to scratching
> a very specific itch) it's still simply an honest and rational response
> to an incentive offered by the foundation.
> 
> One could argue whether the incentive is mis-designed, but that doesn't
> IMO make a gamer of any contributor who simply meets the required threshold
> of activity.
> 
> Cheers,
> Eoghan
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

No I'm not saying that. I'm saying that the larger issue is one of
motivation.

Folks who want to help (even if they don't know how yet) carry an energy
of intention with them which is nourishing to be around. Folks who are
trying to get in the door and not be expected to help and hope noone
notices carry an entirely different kind of energy with them. It is a
non-nourishing energy.

Ratios also come into play, if you have a group that is 98% nourishing
and 2% not nourishing then I can tolerate that. But when the ratios
start to tip (and I have no hard numbers for this as some folks carry
energy equal to three other people, plus energy can fluctuate) then we
move to the non-nourishing position.

I'm saying I'm in favour of spending time with folks with energy that is
mutually beneficial and nourishing for me. I don't have any way of
translating that to numbers or passes or gerrit actions, but that is the
best I can offer.

Thanks,
Anita.

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Eoghan Glynn]

> >>> Current thinking would be to give preferential rates to access the main
> >>> summit to people who are present to other events (like this new
> >>> separated contributors-oriented event, or Ops midcycle(s)). That would
> >>> allow for a wider definition of "active community member" and reduce
> >>> gaming.
> >>>
> >>
> >> I think reducing gaming is important. It is valuable to include those
> >> folks who wish to make a contribution to OpenStack, I have confidence
> >> the next iteration of entry structure will try to more accurately
> >> identify those folks who bring value to OpenStack.
> > 
> > There have been a couple references to "gaming" on this thread, which
> > seem to imply a certain degree of dishonesty, in the sense of bending
> > the rules.
> > 
> > Can anyone who has used the phrase clarify:
> > 
> >  (a) what exactly they mean by gaming in this context
> > 
> > and:
> > 
> >  (b) why they think this is a clear & present problem demanding a
> >  solution?
> > 
> > For the record, landing a small number of patches per cycle and thus
> > earning an ATC summit pass as a result is not, IMO at least, gaming.
> > 
> > Instead, it's called *contributing*.
> > 
> > (on a small scale, but contributing none-the-less).
> > 
> > Cheers,
> > Eoghan
> 
> Sure I can tell you what I mean.
> 
> In Vancouver I happened to be sitting behind someone who stated "I'm
> just here for the buzz." Which is lovely for that person. The problem is
> that the buzz that person is there for is partially created by me and I
> create it and mean to offer it to people who will return it in kind, not
> just soak it up and keep it to themselves.
> 
> Now I have no way of knowing who this person is and how they arrived at
> the event. But the numbers for people offering one patch to OpenStack
> (the bar for a summit pass) is significantly higher than the curve of
> people offering two, three or four patches to OpenStack (patches that
> are accepted and merged). So some folks are doing the minimum to get a
> summit pass rather than being part of the cohort that has their first
> patch to OpenStack as a means of offering their second patch to OpenStack.
> 
> I consider it an honour and a privilege that I get to work with so many
> wonderful people everyday who are dedicated to making open source clouds
> available for whoever would wish to have clouds. I'm more than a little
> tired of having my energy drained by folks who enjoy feeding off of it
> while making no effort to return beneficial energy in kind.
> 
> So when I use the phrase gaming, this is the dynamic to which I refer.

Thanks for the response.

I don't know if drive-by attendance at design summit sessions by under-
qualified or uninformed summiteers is encouraged by the availability of
ATC passes. But as long as those individuals aren't actively derailing
the conversation in sessions, I wouldn't consider their buzz soakage as
a major issue TBH. 

In any case, I would say that just meeting the bar for an ATC summit pass
(by landing the required number of patches) is not bending the rules or
misrepresenting in any way.

Even if specifically motivated by the ATC pass (as opposed to scratching
a very specific itch) it's still simply an honest and rational response
to an incentive offered by the foundation.

One could argue whether the incentive is mis-designed, but that doesn't
IMO make a gamer of any contributor who simply meets the required threshold
of activity.

Cheers,
Eoghan


__
OpenStack Development Mailing 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] Vlan Tenant network

[Shinobu Kinjo]

That is a great guide.

Cheers,

On Mon, Feb 29, 2016 at 5:20 PM, Andreas Scheuring
 wrote:
> Hi Pratti,
> yes, this is working! For Openvswitch ml2 driver just configure on the
> neutron server in the ml2 configuration file [1][2]
>
> [ml2]
> tenant_network_types = flat
> type_drivers = local, flat, vlan, gre, vxlan
>
> [ml2_type_vlan]
> network_vlan_ranges = physnet1:30:40  #where 30-40 is the range of vlan
> to use
>
>
> And in the ovs agent config file (on the network and on each compute
> node) [3]
>
> [ovs]
> bridge_mappings=physnet1:br-ethx  #where ethx is the
> interface in the hypervisor to create the vlans on
>
>
>
> Probably you have to create the ovs bridge br-ethx by hand and you need
> to add the ethx interface as port into this bridge
>> ovs-vsctl add-br br-ethx
>> ovs-vsctl add-port br-ethx ethx
>
>
> Hope that helps
>
> [1]
> http://docs.openstack.org/kilo/config-reference/content/networking-options-plugins-ml2.html
>
> [2]
> http://docs.openstack.org/kilo/config-reference/content/networking-plugin-ml2_vlan.html
> [3]
> http://docs.openstack.org/kilo/config-reference/content/networking-plugin-openvswitch_agent.html
> --
> -
> Andreas (IRC: scheuran)
>
> On So, 2016-02-28 at 13:17 +0530, pratik maru wrote:
>> Hi All,
>>
>>
>>
>>
>>
>>
>> I would like to to know if it is possible in openstack to configure
>> vlan network for communication between two VM's data plane nic cards,
>> i.e. tenant networks.  If yes, can someone please share the
>> configurations and steps ?
>>
>> More details : I am trying to launch VM's with 3 nics ( eth0-2), and i
>> want eth0 to come from a mgmt network, which i have configured as flat
>> type and I want other two interfaces ( i.e. eth1 and eth2 , which i
>> will be using for communication between VM instances) to use vlan type
>> network.
>>
>>
>> Regards
>>
>> Prati
>>
>>
>> __
>> OpenStack Development Mailing 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
OpenStack Development Mailing 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] solving API case sensitivity issues

[melanie witt]

On Feb 25, 2016, at 8:35, Michał Dulko  wrote:

> We've faced similar issues in Cinder and as solution we've moved
> filtering to Python code. Like in for example [1] or [2]. But no, we
> haven't had UNIQUE constraint on the DB column in these cases, only on IDs.

This is an interesting option.

I see how option 1 (API case fold) is appealing, since our underlying storage 
(in the mysql case), is case insensitive. And when I think about it, I could 
see how for example "abc" is essentially the same thing as "ABC" and would be 
resilient to end users making differences in capitalization of metadata keys 
(imagine a typo of "DriveType" vs "Drivetype" where a user expects to set a 
value for the key and they are treated as different keys).

The only concern I have about the case folding is when the data is visible to 
the user. That is, if a user sets a value for "DriveType" and they do 'nova 
aggregate-details' and see "drivetype" displayed, different than they specified 
or expected. In the case of aggregate metadata it doesn't seem too impactful 
since nova is supposed to be the only consumer of the metadata. But are we 
considering this as the consistent behavior across all APIs?

-melanie








signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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] A proposal to separate the design summit

[James Bottomley]

On Mon, 2016-02-29 at 17:48 -0500, Anita Kuno wrote:
> On 02/29/2016 05:34 PM, James Bottomley wrote:
[...]
> > While I accept there is potentially a gaming problem in all forms 
> > of Open Source (we see this in the kernel with the attempt to boost
> > patch counts with trivial changes), I'd be hesitant to characterise
> > people who only submit a single patch as gamers because there's a 
> > lot of drive by patching that goes on in the long tail of any 
> > project.  The usual reason for this is everything works great apart 
> > from one thing, which the person gets annoyed enough over to 
> > investigate and patch.  I've done it myself in a lot of Open Source 
> > projects.  Once your patch is in, you've no need to submit another 
> > because everything is now working as you wished and your goal was 
> > to fix the problem not become further involved in the development 
> > side of things.  I suspect if you look in the long tail of 
> > OpenStack you'll find a lot of user and operator patches for
> > precisely this reason.
> 
> I think you are missing the point of my explanation to the question I
> was asked.
> 
> I am interested in mutually beneficial interactions.
> 
> I am not interested in unbalanced or one sided interactions.
> 
> Sorry I was unclear earlier.

Well, now I'm confused.  I was responding specifically to this
statement:

> So some folks are doing the minimum to get a summit pass rather than 
> being part of the cohort that has their first patch to OpenStack as a 
> means of offering their second patch to OpenStack.

Is that not who you meant by "gamers"? because to me it sounds like an
an expectation that people who aren't gamers would submit more than one
patch and, indeed, become part of the developer base.  I wanted to
explain why there's a significant set of people who legitimately only
submit a single patch and who won't really ever become developers.

James


__
OpenStack Development Mailing 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] [devstack] [neutron] How to ask for linuxbridge instead of openvswitch

[Mike Spreitzer]

How would I modify the recipe at 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
to get linuxbridge instead of openvswitch?

Thanks,
Mike



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

Re: [openstack-dev] [fuel] Fuel plugins: lets have some rules

[Dmitry Borodaenko]

On Mon, Feb 29, 2016 at 08:21:18AM +0100, Andreas Jaeger wrote:
> > Yes, they will officially become a part of Fuel project. First such
> > example is likely to be the Murano plugin [0], so we can use it a the
> > guinea pig to try out this process.
> > 
> > [0] https://review.openstack.org/269567
> > 
> > As described in the corresponding spec [1], we plan this plugin to
> > co-exist with the current non-plugin implementation for Mitaka, and then
> > let the legacy non-plugin implementation be superceded by
> > fuel-plugin-murano as soon as the latter reaches maturity (hopefully
> > early in Newton cycle).
> > 
> > [1] https://review.openstack.org/275124
> 
> Why is the corresponding spec not mentioned as part of the infra change?

We updated the change to reference the blueprint which in turn links to
this spec.

> > Since this is not a straight-forward moving of existing code into its
> > own git repo (like we've recently done for fuel-virtualbox and fuel-ui),
> > I think it's too early to register the new plugin repo in
> > openstack/governance, but eventually (as soon as it's ready to become
> > the default way to deploy Murano with Fuel) we should add it there.
> 
> That's not a reason under the big tent to not add it to the governance
> documentation. There's no need to incubate it outside the tree.

Fair enough. I've posted a governance change and linked it to the infra
change:

https://review.openstack.org/286310

-- 
Dmitry Borodaenko

__
OpenStack Development Mailing 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] A proposal to separate the design summit

[Anita Kuno]

On 02/29/2016 05:34 PM, James Bottomley wrote:
> On Mon, 2016-02-29 at 15:57 -0500, Anita Kuno wrote:
>> On 02/29/2016 03:10 PM, Eoghan Glynn wrote:
>>>
> Current thinking would be to give preferential rates to access 
> the main summit to people who are present to other events (like 
> this new separated contributors-oriented event, or Ops 
> midcycle(s)). That would allow for a wider definition of 
> "active community member" and reduce gaming.
>

 I think reducing gaming is important. It is valuable to include 
 those folks who wish to make a contribution to OpenStack, I have
 confidence the next iteration of entry structure will try to more 
 accurately identify those folks who bring value to OpenStack.
>>>
>>> There have been a couple references to "gaming" on this thread, 
>>> which seem to imply a certain degree of dishonesty, in the sense of
>>> bending the rules.
>>>
>>> Can anyone who has used the phrase clarify:
>>>
>>>  (a) what exactly they mean by gaming in this context
>>>
>>> and:
>>>
>>>  (b) why they think this is a clear & present problem demanding a
>>>  solution?
>>>
>>> For the record, landing a small number of patches per cycle and 
>>> thus earning an ATC summit pass as a result is not, IMO at least,
>>> gaming.
>>>
>>> Instead, it's called *contributing*.
>>>
>>> (on a small scale, but contributing none-the-less).
>>>
>>> Cheers,
>>> Eoghan
>>>
>>> ___
>>> ___
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
>>> bscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> Sure I can tell you what I mean.
>>
>> In Vancouver I happened to be sitting behind someone who stated "I'm
>> just here for the buzz." Which is lovely for that person. The problem 
>> is that the buzz that person is there for is partially created by me 
>> and I create it and mean to offer it to people who will return it in 
>> kind, not just soak it up and keep it to themselves.
> 
> Sorry about that; it does sound like a thing a sales or marketing
> person would say.

I would hardly expect you to take responsibility for someone else's
behaviour. It feels odd to me that you would try.

> 
>> Now I have no way of knowing who this person is and how they arrived
>> at the event. But the numbers for people offering one patch to
>> OpenStack (the bar for a summit pass) is significantly higher than
>> the curve of people offering two, three or four patches to OpenStack
>> (patches that are accepted and merged). So some folks are doing the
>> minimum to get a summit pass rather than being part of the cohort
>> that has their first patch to OpenStack as a means of offering their
>> second patch to OpenStack.
> 
> Which does sound like the ATC inducement is working.  If you don't want
> it to encourage people to submit patches then it shouldn't be offered.

I didn't offer it. And personally I do want people to submit patches. It
is their motivation for doing so that I am drawing attention to.

> 
>> I consider it an honour and a privilege that I get to work with so 
>> many wonderful people everyday who are dedicated to making open 
>> source clouds available for whoever would wish to have clouds. I'm 
>> more than a little tired of having my energy drained by folks who 
>> enjoy feeding off of it while making no effort to return beneficial
>> energy in kind.
>>
>> So when I use the phrase gaming, this is the dynamic to which I 
>> refer.
> 
> While I accept there is potentially a gaming problem in all forms of
> Open Source (we see this in the kernel with the attempt to boost patch
> counts with trivial changes), I'd be hesitant to characterise people
> who only submit a single patch as gamers because there's a lot of drive
> by patching that goes on in the long tail of any project.  The usual
> reason for this is everything works great apart from one thing, which
> the person gets annoyed enough over to investigate and patch.  I've
> done it myself in a lot of Open Source projects.  Once your patch is
> in, you've no need to submit another because everything is now working
> as you wished and your goal was to fix the problem not become further
> involved in the development side of things.  I suspect if you look in
> the long tail of OpenStack you'll find a lot of user and operator
> patches for precisely this reason.

I think you are missing the point of my explanation to the question I
was asked.

I am interested in mutually beneficial interactions.

I am not interested in unbalanced or one sided interactions.

Sorry I was unclear earlier.

Thanks,
Anita.

> 
> James
> 


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

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

[Robert Kukura]

Is Manila actually connecting (i.e. binding) something it controls to a 
Neutron port, similar to how a Neutron L3 or DHCP agent connects a 
network namespace to a port? Or does it just need to know the details 
about a port bound for a VM (or a service)?


If the former, it should probably be using something similar to 
Neutron's interface drivers (or maybe Nova's new VIF library) so it can 
work with arbitrary core plugins or ML2 mechanism drivers, and any 
corresponding L2 agent. If it absolutely requires a VLAN on a node's 
physical network, then Kevin's idea of a Manila-specific mechanism 
driver that does the binding (without involving an L2 agent) may be the 
way to go.


-Bob

On 2/29/16 4:38 PM, Kevin Benton wrote:
You're correct. Right now there is no way via the HTTP API to find 
which segments a port is bound to.
This is something we can certainly consider adding, but it will need 
an RFE so it wouldn't land until Newton at the earliest.


Have you considered writing an ML2 driver that just notifies Manilla 
of the port's segment info? All of this information is available to 
ML2 drivers in the PortContext object that is passed to them.


On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka > wrote:


Fixed neutron tag in the subject.

Marc > wrote:

Hi Neutron team,

I am currently working on a feature for hierarchical port
binding support in
Manila [1] [2]. Just to give some context: In the current
implementation Manila
creates a neutron port but let it unbound (state DOWN).
Therefore Manila uses
the port create only retrieve an IP address and segmentation
ID (some drivers
only support VLAN here).

My idea is to change this behavior and do an actual port
binding action so that
the configuration of VLAN isn’t a manual job any longer. And
that multi-segment
and HPB is supported on the long-run.

My current issue is: How can Manila retrieve the segment
information for a
bound port? Manila only is interested in the last (bottom)
segmentation ID
since I assume the storage is connected to a ToR switch.

Database-wise it’s possible to query it using
ml2_port_binding_levels table.
But AFAIK there is no API to query this. The only information
that is exposed
are all segments of a network. But this is not sufficient to
identify which
segments actually used for a port binding.

Regards
Marc
SAP SE

[1]:
https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support
[2]: https://review.openstack.org/#/c/277731/

__
OpenStack Development Mailing 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] [all] A proposal to separate the design summit

[James Bottomley]

On Mon, 2016-02-29 at 15:57 -0500, Anita Kuno wrote:
> On 02/29/2016 03:10 PM, Eoghan Glynn wrote:
> > 
> > > > Current thinking would be to give preferential rates to access 
> > > > the main summit to people who are present to other events (like 
> > > > this new separated contributors-oriented event, or Ops 
> > > > midcycle(s)). That would allow for a wider definition of 
> > > > "active community member" and reduce gaming.
> > > > 
> > > 
> > > I think reducing gaming is important. It is valuable to include 
> > > those folks who wish to make a contribution to OpenStack, I have
> > > confidence the next iteration of entry structure will try to more 
> > > accurately identify those folks who bring value to OpenStack.
> > 
> > There have been a couple references to "gaming" on this thread, 
> > which seem to imply a certain degree of dishonesty, in the sense of
> > bending the rules.
> > 
> > Can anyone who has used the phrase clarify:
> > 
> >  (a) what exactly they mean by gaming in this context
> > 
> > and:
> > 
> >  (b) why they think this is a clear & present problem demanding a
> >  solution?
> > 
> > For the record, landing a small number of patches per cycle and 
> > thus earning an ATC summit pass as a result is not, IMO at least,
> > gaming.
> > 
> > Instead, it's called *contributing*.
> > 
> > (on a small scale, but contributing none-the-less).
> > 
> > Cheers,
> > Eoghan
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> Sure I can tell you what I mean.
> 
> In Vancouver I happened to be sitting behind someone who stated "I'm
> just here for the buzz." Which is lovely for that person. The problem 
> is that the buzz that person is there for is partially created by me 
> and I create it and mean to offer it to people who will return it in 
> kind, not just soak it up and keep it to themselves.

Sorry about that; it does sound like a thing a sales or marketing
person would say.

> Now I have no way of knowing who this person is and how they arrived
> at the event. But the numbers for people offering one patch to
> OpenStack (the bar for a summit pass) is significantly higher than
> the curve of people offering two, three or four patches to OpenStack
> (patches that are accepted and merged). So some folks are doing the
> minimum to get a summit pass rather than being part of the cohort
> that has their first patch to OpenStack as a means of offering their
> second patch to OpenStack.

Which does sound like the ATC inducement is working.  If you don't want
it to encourage people to submit patches then it shouldn't be offered.

> I consider it an honour and a privilege that I get to work with so 
> many wonderful people everyday who are dedicated to making open 
> source clouds available for whoever would wish to have clouds. I'm 
> more than a little tired of having my energy drained by folks who 
> enjoy feeding off of it while making no effort to return beneficial
> energy in kind.
> 
> So when I use the phrase gaming, this is the dynamic to which I 
> refer.

While I accept there is potentially a gaming problem in all forms of
Open Source (we see this in the kernel with the attempt to boost patch
counts with trivial changes), I'd be hesitant to characterise people
who only submit a single patch as gamers because there's a lot of drive
by patching that goes on in the long tail of any project.  The usual
reason for this is everything works great apart from one thing, which
the person gets annoyed enough over to investigate and patch.  I've
done it myself in a lot of Open Source projects.  Once your patch is
in, you've no need to submit another because everything is now working
as you wished and your goal was to fix the problem not become further
involved in the development side of things.  I suspect if you look in
the long tail of OpenStack you'll find a lot of user and operator
patches for precisely this reason.

James


__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Matt Riedemann]

On 2/29/2016 2:54 PM, Sean Dague wrote:

On 02/29/2016 11:59 AM, Sean Dague wrote:

The nova/hooks.py infrastructure has been with us since early Nova. It's
currently only annotated on a few locations - 'build_instance',
'create_instance', 'delete_instance', and 'instance_network_info'. It's
got a couple of unit tests on it, but nothing that actually tests real
behavior of the hooks we have specified.

It does get used in the wild, and we do break it with changes we didn't
ever anticipate would impact it -
https://bugs.launchpad.net/nova/+bug/1518321

However, when you look into how that is used, it's really really odd and
fragile -
https://github.com/richm/rdo-vm-factory/blob/master/rdo-ipa-nova/novahooks.py#L248


 def pre(self, *args, **kwargs):
 # args[7] is the injected_files parameter array
 # the value is ('filename', 'base64 encoded contents')
 ipaotp = str(uuid.uuid4())
 ipainject = ('/tmp/ipaotp', base64.b64encode(ipaotp))
 args[7].extend(self.inject_files)
 args[7].append(ipainject)

In our continued quest on being more explicit about plug points it feels
like we should other document the interface (which means creating
stability on the hook parameters) or we should deprecate this construct
as part of a bygone era.

I lean on deprecation because it feels like a thing we don't really want
to support going forward, but I can go either way.

-Sean

P.S. I'm starting to look at in tree functional testing for all of this,
in the event that we decide not to deprecate it. It's definitely made a
little hard by the way all exceptions are caught when hooks go wrong.


As there seemed to be some early enthusiasm for this from the core team,
the deprecation patch is proposed here -
https://review.openstack.org/#/c/286276/

Unless there is a big reversal of sentiment I'd suggest we get that
landed in Mitaka so that this is signalled to people going forward, and
we can collect use cases for things that are currently using hooks that
we may want to support in other ways in Newton.

-Sean



I think you should probably also post this to the operators mailing list 
before we actually deprecate hooks.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [Neutron] DocImpact flag: a kind reminder

[Armando M.]

Hi Neutrinos,

Please remember that what you decorate a commit message with DocImpact,
this must be followed by a brief description of the documentation impact
[1]. Also, please be aware that currently, as soon as the patch merges, a
bug report is filed against the Launchpad project of the targeted repo.
This is tagged with 'doc' and '' [2].

So, if you have a train of patches affecting the same feature (client side,
server side, *-aas projects etc), be mindful to where you put the tag and
avoid adding DocImpact to more than one commit message, unless the
documentation target is indeed meant to be separate.

Cheers,
Armando

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080294.html
[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
__
OpenStack Development Mailing 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] Re-booting the SR-IOV meeting

[Shinobu Kinjo]

> Hi - so I think that one of the main goals of the meeting tomorrow will
> be to figure out a list of fixes we want to have reviewed and hopefully
> merged in Mitaka.

Understood.

> 
> I don't there is a straightforward and exhaustive way to find these (one
> trick I use is to look for changes that touch a certain file, so
> everything under nova/pci/ would be suspect, but there may be more).
> This is why I think it would be good to meet and figure this out together.

I hope that there would be specific goal and do some work for this goal.
Requirement of the SR-IOV feature would be more high, I guess.

Cheers,

- Original Message -
From: "Nikola Đipanov" 
To: ski...@redhat.com, "OpenStack Development Mailing List (not for usage 
questions)" 
Sent: Tuesday, March 1, 2016 12:26:37 AM
Subject: Re: [openstack-dev] [Nova] Re-booting the SR-IOV meeting

On 02/26/2016 10:35 PM, Shinobu Kinjo wrote:
> Hello,
> 
> Thank you for your message.
> Is there any list of only SR-IOV related bugfixes? If there is any
> pointer, that would be very useful.
> 
> Cheers,
> Shinobu
> 
> 
> On Fri, Feb 26, 2016 at 11:58 PM, Nikola Đipanov  wrote:
>> Hello folks,
>>
>> We are closing in on Mitaka-3 and it would be good to have a meeting and
>> see which SR-IOV related bugfixes we want to try to land for Mitaka.
>>
>> The next meeting slot is next week on Tuesday (March 1st) at 13:00 UTC,
>> so if there are any bugs you would like to discuss - that would be a
>> good place.
>>
>> The meeting times haven't changed - but there was not a lot of
>> interested parties for the last couple of meetings, so I thought I
>> should send an email to remind folks that the meeting is still on :)
>>
>> Talk to you then,
>>
>> Cheers,
>> N.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 


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

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

[Madhusudhan Kandadai]

Is what I can see the error logs in barbican svc screen while I create TLS
listener like this: http://paste.openstack.org/show/xVl9iuJtGW03fCGetDm3/

2016-02-29 13:42:55.222 INFO barbican.api.middleware.context
[req-65fd0f08-4c1e-4b2f-9cbd-64f186365077 afaa5d797f3543369d05e370a543ef9d
c141e106a7424d1a8316cf03a8c91e40] Processed request: 404 Not Found - POST
http://192.168.109.129:9311/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/
{address space usage: 220770304 bytes/210MB} {rss usage: 101371904
bytes/96MB} [pid: 52558|app: 0|req: 75/75] 192.168.109.129 () {34 vars in
598 bytes} [Mon Feb 29 13:42:55 2016] POST
/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/ => generated
111 bytes in 214 msecs (HTTP/1.1 404) 4 headers in 179 bytes (1 switches on
core 0)
2016-02-29 13:43:17.397 ERROR barbican.model.repositories
[req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
c141e106a7424d1a8316cf03a8c91e40] Not found for
d96dccd5-0d39-4f67-ba3a-366a84cfd371
2016-02-29 13:43:17.397 TRACE barbican.model.repositories Traceback (most
recent call last):
2016-02-29 13:43:17.397 TRACE barbican.model.repositories   File
"/opt/stack/barbican/barbican/model/repositories.py", line 354, in get
2016-02-29 13:43:17.397 TRACE barbican.model.repositories entity =
query.one()
2016-02-29 13:43:17.397 TRACE barbican.model.repositories   File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py", line
2699, in one
2016-02-29 13:43:17.397 TRACE barbican.model.repositories raise
orm_exc.NoResultFound("No row was found for one()")
2016-02-29 13:43:17.397 TRACE barbican.model.repositories NoResultFound: No
row was found for one()
2016-02-29 13:43:17.397 TRACE barbican.model.repositories
2016-02-29 13:43:17.398 ERROR barbican.api.controllers
[req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
c141e106a7424d1a8316cf03a8c91e40] Webob error seen
2016-02-29 13:43:17.398 TRACE barbican.api.controllers Traceback (most
recent call last):
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/opt/stack/barbican/barbican/api/controllers/__init__.py", line 104, in
handler
2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
*args, **kwargs)
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/opt/stack/barbican/barbican/api/controllers/__init__.py", line 90, in
enforcer
2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
*args, **kwargs)
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/opt/stack/barbican/barbican/api/controllers/__init__.py", line 146, in
content_types_enforcer
2016-02-29 13:43:17.398 TRACE barbican.api.controllers return fn(inst,
*args, **kwargs)
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/opt/stack/barbican/barbican/api/controllers/consumers.py", line 143, in
on_post
2016-02-29 13:43:17.398 TRACE barbican.api.controllers
controllers.containers.container_not_found()
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/opt/stack/barbican/barbican/api/controllers/containers.py", line 36, in
container_not_found
2016-02-29 13:43:17.398 TRACE barbican.api.controllers pecan.abort(404,
u._('Not Found. Sorry but your container is in '
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/usr/local/lib/python2.7/dist-packages/pecan/core.py", line 141, in abort
2016-02-29 13:43:17.398 TRACE barbican.api.controllers exec('raise
webob_exception, None, traceback')
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/opt/stack/barbican/barbican/api/controllers/consumers.py", line 141, in
on_post
2016-02-29 13:43:17.398 TRACE barbican.api.controllers
external_project_id)
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/opt/stack/barbican/barbican/model/repositories.py", line 360, in get
2016-02-29 13:43:17.398 TRACE barbican.api.controllers
_raise_entity_not_found(self._do_entity_name(), entity_id)
2016-02-29 13:43:17.398 TRACE barbican.api.controllers   File
"/opt/stack/barbican/barbican/model/repositories.py", line 2173, in
_raise_entity_not_found
2016-02-29 13:43:17.398 TRACE barbican.api.controllers id=entity_id))
2016-02-29 13:43:17.398 TRACE barbican.api.controllers HTTPNotFound: Not
Found. Sorry but your container is in another castle.
2016-02-29 13:43:17.398 TRACE barbican.api.controllers
2016-02-29 13:43:17.403 INFO barbican.api.middleware.context
[req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d
c141e106a7424d1a8316cf03a8c91e40] Processed request: 404 Not Found - POST
http://192.168.109.129:9311/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/
{address space usage: 220770304 bytes/210MB} {rss usage: 101371904
bytes/96MB} [pid: 52558|app: 0|req: 76/76] 192.168.109.129 () {34 vars in
598 bytes} [Mon Feb 29 13:43:17 2016] POST
/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/ => generated
111 bytes in 63 msecs (HTTP/1.1 404) 4 headers in 

[openstack-dev] [salt] Team meeting this Tuesday

[Clark, Jay]

Hi Saltstackers,

A kind reminder for this week's #openstack-salt meeting. More on the agenda [1].

[1]. https://wiki.openstack.org/wiki/Meetings/openstack-salt

Regards,
Jay Clark
Sr. OpenStack Deployment Engineer
E: jason.t.cl...@hpe.com
H: 919.341.4670
M: 919.345.1127
IRC (freenode): jasondotstar


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

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

[Phillip Toohill]

To further my thoughts, as Adam mentioned, it could be a user issue, which to 
me is what it sounds like. So being able to view the config and have other 
information is pertinent to solving the issue.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374




From: Phillip Toohill 
Sent: Monday, February 29, 2016 3:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not 
be found


We could use some more information.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374




From: Madhusudhan Kandadai 
Sent: Monday, February 29, 2016 3:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not 
be found

Wondering, have you guys figured out this issue? I am seeing the same problem 
that Jiahao is getting.

On Thu, Feb 4, 2016 at 9:53 AM, Adam Harwell 
> wrote:

Could you provide your neutron-lbaas.conf? Depending on what version you're 
using, barbican may not be the default secret backend (I believe this has been 
fixed). Alternatively, it depends on what user accounts are involved -- this 
should definitely work if you are using only the single admin account, but we 
haven't done a lot of testing around the ACLs yet to make sure they are working 
(and I believe there is still an outstanding bug in Barbican that would cause 
the ACLs to not function properly in our use-case).


--Adam



From: Jiahao Liang 
>
Sent: Thursday, January 28, 2016 12:18 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be 
found

Hi community,

I was going through 
https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer
 with devstack. I was stuck at a point when I tried to create a listener within 
a loadbalancer with this command:

neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 --protocol 
TERMINATED_HTTPS --name listener1 --default-tls-container=$(barbican secret 
container list | awk '/ tls_container / {print $2}')

But the command failed with output:

TLS container 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
could not be found

When I run:

barbican secret container list

I was able to see the corresponding container in the list and the status is 
active.
(Sorry, the format is a little bit ugly.)
+++---++-+-+---+
| Container href
 | Name   | Created   | Status | Type| Secrets  
   
| Consumers |
+++---++-+-+---+
| 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
| tls_container  | 2016-01-28 04:58:42+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/1bbe33fc-ecd2-43e5-82ce-34007b9f6bfd
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/6d0211c6-8515-4e55-b1cf-587324a79abe
 |   |
| 
http://192.168.100.149:9311/v1/containers/31045466-bf7b-426f-9ba8-135c260418ee 
| tls_container2 | 2016-01-28 04:59:05+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/dba18cbc-9bfe-499e-931e-90574843ca10
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/23e11441-d119-4b24-a288-9ddc963cb698
 |   |

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

[Kevin Benton]

You're correct. Right now there is no way via the HTTP API to find which
segments a port is bound to.
This is something we can certainly consider adding, but it will need an RFE
so it wouldn't land until Newton at the earliest.

Have you considered writing an ML2 driver that just notifies Manilla of the
port's segment info? All of this information is available to ML2 drivers in
the PortContext object that is passed to them.

On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka 
wrote:

> Fixed neutron tag in the subject.
>
> Marc  wrote:
>
> Hi Neutron team,
>>
>> I am currently working on a feature for hierarchical port binding support
>> in
>> Manila [1] [2]. Just to give some context: In the current implementation
>> Manila
>> creates a neutron port but let it unbound (state DOWN). Therefore Manila
>> uses
>> the port create only retrieve an IP address and segmentation ID (some
>> drivers
>> only support VLAN here).
>>
>> My idea is to change this behavior and do an actual port binding action
>> so that
>> the configuration of VLAN isn’t a manual job any longer. And that
>> multi-segment
>> and HPB is supported on the long-run.
>>
>> My current issue is: How can Manila retrieve the segment information for a
>> bound port? Manila only is interested in the last (bottom) segmentation ID
>> since I assume the storage is connected to a ToR switch.
>>
>> Database-wise it’s possible to query it using ml2_port_binding_levels
>> table.
>> But AFAIK there is no API to query this. The only information that is
>> exposed
>> are all segments of a network. But this is not sufficient to identify
>> which
>> segments actually used for a port binding.
>>
>> Regards
>> Marc
>> SAP SE
>>
>> [1]:
>> https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support
>> [2]: https://review.openstack.org/#/c/277731/
>> __
>> OpenStack Development Mailing 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] [kolla] unblocking the gate

[Sam Yaple]

On Mon, Feb 29, 2016 at 6:42 PM, Clark Boylan  wrote:

> On Mon, Feb 29, 2016, at 09:09 AM, Steven Dake (stdake) wrote:
> >
> >
> > On 2/29/16, 12:26 AM, "Andreas Jaeger"  wrote:
> > >This is not needed, the CI system always rebases if you run tests. To
> > >get current tests, a simple "recheck" is enough.
> > >
> > >Also, we test in the gate before merging - again after rebasing to head.
> > >That should take care of not merging anything broken. Running recheck
> > >after a larger change will ensure that you have recent results.
> >
> > Andreas,
> >
> > Thanks for the recheck information.  I thought the gate ran against what
> > it was submitted with as head.  We don't have any gate jobs at present
> > (or
> > many) they are mostly check jobs, so its pre-merge checking that we need
> > folks to do.
> >
> To clarify the check pipeline changes are merged into their target
> branches before testing and the gate pipeline changes are merged into
> the forward looking state of the world that Zuul generates as part of
> gate testing. This means you do not need to rebase and create new
> patchsets to get updated test results, just recheck.
>
>
Unfortunately we do not have voting gates in Kolla that do building and
deploying. This will change soon, but that would be where the confusion in
the thread is coming from I believe. Our only indication is a "Green" check
job at this time. This is why Steven is asking for a rebase to make the
check gates green before we merge new patches.

You should only need to rebase and create a new patchset if a merge
> conflict exists.
>
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

[Phillip Toohill]

We could use some more information.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374




From: Madhusudhan Kandadai 
Sent: Monday, February 29, 2016 3:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not 
be found

Wondering, have you guys figured out this issue? I am seeing the same problem 
that Jiahao is getting.

On Thu, Feb 4, 2016 at 9:53 AM, Adam Harwell 
> wrote:

Could you provide your neutron-lbaas.conf? Depending on what version you're 
using, barbican may not be the default secret backend (I believe this has been 
fixed). Alternatively, it depends on what user accounts are involved -- this 
should definitely work if you are using only the single admin account, but we 
haven't done a lot of testing around the ACLs yet to make sure they are working 
(and I believe there is still an outstanding bug in Barbican that would cause 
the ACLs to not function properly in our use-case).


--Adam



From: Jiahao Liang 
>
Sent: Thursday, January 28, 2016 12:18 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be 
found

Hi community,

I was going through 
https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer
 with devstack. I was stuck at a point when I tried to create a listener within 
a loadbalancer with this command:

neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 --protocol 
TERMINATED_HTTPS --name listener1 --default-tls-container=$(barbican secret 
container list | awk '/ tls_container / {print $2}')

But the command failed with output:

TLS container 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
could not be found

When I run:

barbican secret container list

I was able to see the corresponding container in the list and the status is 
active.
(Sorry, the format is a little bit ugly.)
+++---++-+-+---+
| Container href
 | Name   | Created   | Status | Type| Secrets  
   
| Consumers |
+++---++-+-+---+
| 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
| tls_container  | 2016-01-28 04:58:42+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/1bbe33fc-ecd2-43e5-82ce-34007b9f6bfd
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/6d0211c6-8515-4e55-b1cf-587324a79abe
 |   |
| 
http://192.168.100.149:9311/v1/containers/31045466-bf7b-426f-9ba8-135c260418ee 
| tls_container2 | 2016-01-28 04:59:05+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/dba18cbc-9bfe-499e-931e-90574843ca10
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/23e11441-d119-4b24-a288-9ddc963cb698
 |   |
+++---++-+-+---+


Also, if I did a GET method from a RESTful client with correct X-Auth-Token to 
the url: 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e3, 
I was able to receive the JSON information of the TLS container.


Anybody could give some advice on how to fix this problem?

Thank you in advance!

Best,
Jiahao Liang

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

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

[Madhusudhan Kandadai]

Wondering, have you guys figured out this issue? I am seeing the same
problem that Jiahao is getting.

On Thu, Feb 4, 2016 at 9:53 AM, Adam Harwell 
wrote:

> Could you provide your neutron-lbaas.conf? Depending on what version
> you're using, barbican may not be the default secret backend (I believe
> this has been fixed). Alternatively, it depends on what user accounts are
> involved -- this should definitely work if you are using only the single
> admin account, but we haven't done a lot of testing around the ACLs yet to
> make sure they are working (and I believe there is still an outstanding bug
> in Barbican that would cause the ACLs to not function properly in our
> use-case).
>
>
> ​--Adam
>
>
> --
> *From:* Jiahao Liang 
> *Sent:* Thursday, January 28, 2016 12:18 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [Neutron][LBaaS][barbican]TLS container could
> not be found
>
> Hi community,
>
> I was going through
> https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer
>  with
> devstack. I was stuck at a point when I tried to create a listener within a
> loadbalancer with this command:
>
> neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 
> --protocol TERMINATED_HTTPS --name listener1 
> --default-tls-container=$(barbican secret container list | awk '/ 
> tls_container / {print $2}')
>
> But the command failed with output:
>
> TLS container 
> http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34
>  could not be found
>
>
> When I run:
>
> barbican secret container list
>
> I was able to see the corresponding container in the list and the status
> is active.
> (Sorry, the format is a little bit ugly.)
>
> +++---++-+-+---+
> | Container href
>   | Name   | Created   | Status | Type|
> Secrets
> | Consumers |
>
> +++---++-+-+---+
> |
> http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34
>  |
> tls_container  | 2016-01-28 04:58:42+00:00 | ACTIVE | certificate |
> private_key=
> http://192.168.100.149:9311/v1/secrets/1bbe33fc-ecd2-43e5-82ce-34007b9f6bfd |
> None  |
> |
>||   ||
> | certificate=
> http://192.168.100.149:9311/v1/secrets/6d0211c6-8515-4e55-b1cf-587324a79abe |
>   |
> |
> http://192.168.100.149:9311/v1/containers/31045466-bf7b-426f-9ba8-135c260418ee
>  |
> tls_container2 | 2016-01-28 04:59:05+00:00 | ACTIVE | certificate |
> private_key=
> http://192.168.100.149:9311/v1/secrets/dba18cbc-9bfe-499e-931e-90574843ca10 |
> None  |
> |
>||   ||
> | certificate=
> http://192.168.100.149:9311/v1/secrets/23e11441-d119-4b24-a288-9ddc963cb698 |
>   |
>
> +++---++-+-+---+
>
>
> Also, if I did a GET method from a RESTful client with correct
> X-Auth-Token to the url:
> http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e3,
> I was able to receive the JSON information of the TLS container.
>
>
> Anybody could give some advice on how to fix this problem?
>
> Thank you in advance!
>
> Best,
> Jiahao Liang
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

[Hongbin Lu]

From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: February-29-16 1:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Discussion of supporting single/multiple 
OS distro

Consider this: Which OS runs on the bay nodes is not important to end users. 
What matters to users is the environments their containers execute in, which 
has only one thing in common with the bay
The bay nodes are under user’s tenant. That means end users can to SSH to the 
nodes and play with the containers. Therefore, the choice of OS is important to 
end users.

node OS: the kernel. The linux syscall interface is stable enough that the 
various linux distributions can all run concurrently in neighboring containers 
sharing same kernel. There is really no material reason why the bay OS choice 
must match what distro the container is based on. Although I’m persuaded by 
Hongbin’s concern to mitigate risk of future changes WRT whatever OS distro is 
the prevailing one for bay nodes, there are a few items of concern about 
duality I’d like to zero in on:

1) Participation from Magnum contributors to support the CoreOS specific 
template features has been weak in recent months. By comparison, participation 
relating to Fedora/Atomic have been much stronger.
I have been fixing the CoreOS templates recently. If other contributors are 
willing to work with me on this efforts, it is reasonable to expect the CoreOS 
contribution to be stronger.

2) Properly testing multiple bay node OS distros (would) significantly increase 
the run time and complexity of our functional tests.
This is not true technically. We can re-run the Atomic tests on CoreOS by 
changing a single field (which is the image). What needs to be done is moving 
common modules into a base class and let OS-specific modules inherit from them.

3) Having support for multiple bay node OS choices requires more extensive 
documentation, and more comprehensive troubleshooting details.
This might be true, but we could point to the troubleshooting document of 
specific OS. If the selected OS delivered a comprehensive troubleshooting 
document, this problem is resolved.

If we proceed with just one supported disto for bay nodes, and offer 
extensibility points to allow alternates to be used in place of it, we should 
be able to address the risk concern of the chosen distro by selecting an 
alternate when that change is needed, by using those extensibility points. 
These include the ability to specify your own bay image, and the ability to use 
your own associated Heat template.

I see value in risk mitigation, it may make sense to simplify in the short term 
and address that need when it becomes necessary. My point of view might be 
different if we had contributors willing
I think it becomes necessary now. I have been working on Magnum starting from 
the early stage of the project. Probably, I am the most senior active 
contributor. Based on my experiences, there are a lot of problems of locking in 
a single OS. Basically, all the issues from OS upstream are populated to Magnum 
(e.g. we experienced various known/unknown bugs, pain on image building, lack 
of documentation, lack of upstream support etc.). All these experiences remind 
me not relying on a single OS, because you never know what will be the next 
obstacle.

and ready to address the variety of drawbacks that accompany the strategy of 
supporting multiple bay node OS choices. In absence of such a community 
interest, my preference is to simplify to increase our velocity. This seems to 
me to be a relatively easy way to reduce complexity around heat template 
versioning. What do you think?

Thanks,

Adrian

On Feb 29, 2016, at 8:40 AM, Hongbin Lu 
> wrote:

Hi team,

This is a continued discussion from a review [1]. Corey O'Brien suggested to 
have Magnum support a single OS distro (Atomic). I disagreed. I think we should 
bring the discussion to here to get broader set of inputs.

Corey O'Brien
From the midcycle, we decided we weren't going to continue to support 2 
different versions of the k8s template. Instead, we were going to maintain the 
Fedora Atomic version of k8s and remove the coreos templates from the tree. I 
don't think we should continue to develop features for coreos k8s if that is 
true.
In addition, I don't think we should break the coreos template by adding the 
trust token as a heat parameter.

Hongbin Lu
I was on the midcycle and I don't remember any decision to remove CoreOS 
support. Why you want to remove CoreOS templates from the tree. Please note 
that this is a very big decision and please discuss it with the team 
thoughtfully and make sure everyone agree.

Corey O'Brien
Removing the coreos templates was a part of the COE drivers decision. Since 
each COE driver will only support 1 distro+version+coe we discussed which ones 
to support in tree. The decision was that instead of 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/29/2016 03:10 PM, Eoghan Glynn wrote:
> 
>>> Current thinking would be to give preferential rates to access the main
>>> summit to people who are present to other events (like this new
>>> separated contributors-oriented event, or Ops midcycle(s)). That would
>>> allow for a wider definition of "active community member" and reduce
>>> gaming.
>>>
>>
>> I think reducing gaming is important. It is valuable to include those
>> folks who wish to make a contribution to OpenStack, I have confidence
>> the next iteration of entry structure will try to more accurately
>> identify those folks who bring value to OpenStack.
> 
> There have been a couple references to "gaming" on this thread, which
> seem to imply a certain degree of dishonesty, in the sense of bending
> the rules.
> 
> Can anyone who has used the phrase clarify:
> 
>  (a) what exactly they mean by gaming in this context
> 
> and:
> 
>  (b) why they think this is a clear & present problem demanding a
>  solution?
> 
> For the record, landing a small number of patches per cycle and thus
> earning an ATC summit pass as a result is not, IMO at least, gaming.
> 
> Instead, it's called *contributing*.
> 
> (on a small scale, but contributing none-the-less).
> 
> Cheers,
> Eoghan
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Sure I can tell you what I mean.

In Vancouver I happened to be sitting behind someone who stated "I'm
just here for the buzz." Which is lovely for that person. The problem is
that the buzz that person is there for is partially created by me and I
create it and mean to offer it to people who will return it in kind, not
just soak it up and keep it to themselves.

Now I have no way of knowing who this person is and how they arrived at
the event. But the numbers for people offering one patch to OpenStack
(the bar for a summit pass) is significantly higher than the curve of
people offering two, three or four patches to OpenStack (patches that
are accepted and merged). So some folks are doing the minimum to get a
summit pass rather than being part of the cohort that has their first
patch to OpenStack as a means of offering their second patch to OpenStack.

I consider it an honour and a privilege that I get to work with so many
wonderful people everyday who are dedicated to making open source clouds
available for whoever would wish to have clouds. I'm more than a little
tired of having my energy drained by folks who enjoy feeding off of it
while making no effort to return beneficial energy in kind.

So when I use the phrase gaming, this is the dynamic to which I refer.

Thanks for asking,
Anita.

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

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

[Sean Dague]

On 02/29/2016 11:59 AM, Sean Dague wrote:
> The nova/hooks.py infrastructure has been with us since early Nova. It's
> currently only annotated on a few locations - 'build_instance',
> 'create_instance', 'delete_instance', and 'instance_network_info'. It's
> got a couple of unit tests on it, but nothing that actually tests real
> behavior of the hooks we have specified.
> 
> It does get used in the wild, and we do break it with changes we didn't
> ever anticipate would impact it -
> https://bugs.launchpad.net/nova/+bug/1518321
> 
> However, when you look into how that is used, it's really really odd and
> fragile -
> https://github.com/richm/rdo-vm-factory/blob/master/rdo-ipa-nova/novahooks.py#L248
> 
> 
> def pre(self, *args, **kwargs):
> # args[7] is the injected_files parameter array
> # the value is ('filename', 'base64 encoded contents')
> ipaotp = str(uuid.uuid4())
> ipainject = ('/tmp/ipaotp', base64.b64encode(ipaotp))
> args[7].extend(self.inject_files)
> args[7].append(ipainject)
> 
> In our continued quest on being more explicit about plug points it feels
> like we should other document the interface (which means creating
> stability on the hook parameters) or we should deprecate this construct
> as part of a bygone era.
> 
> I lean on deprecation because it feels like a thing we don't really want
> to support going forward, but I can go either way.
> 
>   -Sean
> 
> P.S. I'm starting to look at in tree functional testing for all of this,
> in the event that we decide not to deprecate it. It's definitely made a
> little hard by the way all exceptions are caught when hooks go wrong.

As there seemed to be some early enthusiasm for this from the core team,
the deprecation patch is proposed here -
https://review.openstack.org/#/c/286276/

Unless there is a big reversal of sentiment I'd suggest we get that
landed in Mitaka so that this is signalled to people going forward, and
we can collect use cases for things that are currently using hooks that
we may want to support in other ways in Newton.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [Manila] NFS and root squash

[Ben Swartzlander]

We haven't spent much time (as a community) discussing root squashing, 
but Rodrigo's migration work has made it clear that we need clearer 
definitions around NFS permissions, and root squashing in particular.


I hope it's obvious to everyone that an NFS share with root squash for 
ALL HOSTS is pretty useless because it's impossible to change ownership 
of files and to create different directories owned by different users. 
The best you can get with root squash turned on for all hosts is an NFS 
share with all files owned by a single user (presumably the "nobody" user).


Now there are use cases for shares where most clients have root squash 
turned on, as long as 1 host has root squash turned off. That 1 host 
would be the "NFS admin" host, where the admin in that case would just 
be a special user who was still a tenant from the Manila perspective. 
Unfortunately we don't have different "access levels" for root squash = 
on/off. This is something to address for Newton.


In the mean time, I hope that everyone agrees that the only sane option 
is for root squash to be disabled by default, and that we need a way to 
allow users to enable it optionally in the future.


If any drivers are currently turning root squash on, I would consider 
that a bug -- and it will prevent migration for working on your backend.


-Ben Swartzlander

__
OpenStack Development Mailing 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] Google Sumer of Code 2016 - Call for ideas and mentors (deadline 19/02/2016)

[Anne Gentle]

Thanks for putting in the effort, Victoria! We learn each year we apply.

Anne

On Mon, Feb 29, 2016 at 2:02 PM, Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> Updates on this topic. Unfortunately we didn't make it for this year.
> We'll apply next year again, thanks all for your support.
>
> Best,
>
> Victoria
>
> 2016-02-15 16:55 GMT-03:00 Victoria Martínez de la Cruz <
> victo...@vmartinezdelacruz.com>:
>
>> Friendly reminder, we are still looking for mentors and internship ideas.
>> Join us [0] and submit your internship project ideas in [1].
>>
>> The deadline for our application as mentoring organization is 19/02/2016
>>
>> [0] https://wiki.openstack.org/wiki/GSoC2016
>> [1] https://wiki.openstack.org/wiki/Internship_ideas
>>
>> 2016-02-01 16:12 GMT-03:00 Victoria Martínez de la Cruz <
>> victo...@vmartinezdelacruz.com>:
>>
>>> Hi all,
>>>
>>> Google Summer of Code (GSoC) is a program that matches mentoring
>>> organizations with college and university student developers who are paid
>>> to write open source code. It has been around 2005 and we had been accepted
>>> as a mentor organization in only one opportunity (2014) having a great
>>> outcome for both interns and for our community. We expect to be able to
>>> join this year again, but for that, we will need your help.
>>>
>>> Mentors
>>>
>>> We need to submit our application as a mentoring organization, but for
>>> that, we need to have a clear outline of what different projects we have
>>> for interns to work on.
>>>
>>> *** The deadline for mentoring organizations applications is
>>> 19/02/2016. ***
>>>
>>> If you are interested in mentoring but you have doubts about it, please
>>> feel free to reach us here or on #openstack-gsoc. We will be happy to reply
>>> any doubt you may have about mentoring for this internship. Also, you can
>>> check out this guide [0].
>>>
>>> If you are already convinced that you want to join us as a mentor for
>>> this round, add your name in the OpenStack Google Summer of Code 2016 wiki
>>> page [1] and add your project ideas in [2]. Make sure you leave your
>>> contact information in the OpenStack GSoC 2016 wiki and that you add all
>>> the important details about the project idea. Also reach us if there is
>>> something you are not certain about.
>>>
>>> Interns
>>>
>>> Whereas we don't know yet if we are going to make it as a mentoring
>>> organization for this round, if you want to join us as an intern and you
>>> want to help OpenStack to get selected as a mentoring organization, you can
>>> help us proposing different tasks for the various projects we have in our
>>> ecosystem.
>>>
>>> For your inspiration, you can check out past projects in [3] and [4].
>>>
>>> Looking forward to see GSoC happening again in our community!
>>>
>>> Thanks,
>>>
>>> Victoria
>>>
>>> [0] http://en.flossmanuals.net/gsocmentoring/
>>> [1] https://wiki.openstack.org/wiki/GSoC2016
>>> [2] https://wiki.openstack.org/wiki/Internship_ideas
>>> [3] https://wiki.openstack.org/wiki/GSoC2014
>>> [4] https://wiki.openstack.org/wiki/GSoC2015
>>>
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.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] [all] A proposal to separate the design summit

[Eoghan Glynn]

> > Current thinking would be to give preferential rates to access the main
> > summit to people who are present to other events (like this new
> > separated contributors-oriented event, or Ops midcycle(s)). That would
> > allow for a wider definition of "active community member" and reduce
> > gaming.
> > 
> 
> I think reducing gaming is important. It is valuable to include those
> folks who wish to make a contribution to OpenStack, I have confidence
> the next iteration of entry structure will try to more accurately
> identify those folks who bring value to OpenStack.

There have been a couple references to "gaming" on this thread, which
seem to imply a certain degree of dishonesty, in the sense of bending
the rules.

Can anyone who has used the phrase clarify:

 (a) what exactly they mean by gaming in this context

and:

 (b) why they think this is a clear & present problem demanding a
 solution?

For the record, landing a small number of patches per cycle and thus
earning an ATC summit pass as a result is not, IMO at least, gaming.

Instead, it's called *contributing*.

(on a small scale, but contributing none-the-less).

Cheers,
Eoghan

__
OpenStack Development Mailing 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] Google Sumer of Code 2016 - Call for ideas and mentors (deadline 19/02/2016)

[Victoria Martínez de la Cruz]

Updates on this topic. Unfortunately we didn't make it for this year. We'll
apply next year again, thanks all for your support.

Best,

Victoria

2016-02-15 16:55 GMT-03:00 Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com>:

> Friendly reminder, we are still looking for mentors and internship ideas.
> Join us [0] and submit your internship project ideas in [1].
>
> The deadline for our application as mentoring organization is 19/02/2016
>
> [0] https://wiki.openstack.org/wiki/GSoC2016
> [1] https://wiki.openstack.org/wiki/Internship_ideas
>
> 2016-02-01 16:12 GMT-03:00 Victoria Martínez de la Cruz <
> victo...@vmartinezdelacruz.com>:
>
>> Hi all,
>>
>> Google Summer of Code (GSoC) is a program that matches mentoring
>> organizations with college and university student developers who are paid
>> to write open source code. It has been around 2005 and we had been accepted
>> as a mentor organization in only one opportunity (2014) having a great
>> outcome for both interns and for our community. We expect to be able to
>> join this year again, but for that, we will need your help.
>>
>> Mentors
>>
>> We need to submit our application as a mentoring organization, but for
>> that, we need to have a clear outline of what different projects we have
>> for interns to work on.
>>
>> *** The deadline for mentoring organizations applications is 19/02/2016.
>> ***
>>
>> If you are interested in mentoring but you have doubts about it, please
>> feel free to reach us here or on #openstack-gsoc. We will be happy to reply
>> any doubt you may have about mentoring for this internship. Also, you can
>> check out this guide [0].
>>
>> If you are already convinced that you want to join us as a mentor for
>> this round, add your name in the OpenStack Google Summer of Code 2016 wiki
>> page [1] and add your project ideas in [2]. Make sure you leave your
>> contact information in the OpenStack GSoC 2016 wiki and that you add all
>> the important details about the project idea. Also reach us if there is
>> something you are not certain about.
>>
>> Interns
>>
>> Whereas we don't know yet if we are going to make it as a mentoring
>> organization for this round, if you want to join us as an intern and you
>> want to help OpenStack to get selected as a mentoring organization, you can
>> help us proposing different tasks for the various projects we have in our
>> ecosystem.
>>
>> For your inspiration, you can check out past projects in [3] and [4].
>>
>> Looking forward to see GSoC happening again in our community!
>>
>> Thanks,
>>
>> Victoria
>>
>> [0] http://en.flossmanuals.net/gsocmentoring/
>> [1] https://wiki.openstack.org/wiki/GSoC2016
>> [2] https://wiki.openstack.org/wiki/Internship_ideas
>> [3] https://wiki.openstack.org/wiki/GSoC2014
>> [4] https://wiki.openstack.org/wiki/GSoC2015
>>
>
>
__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Rich Megginson]

On 02/29/2016 12:19 PM, Chris Friesen wrote:

On 02/29/2016 12:22 PM, Daniel P. Berrange wrote:


There's three core scenarios for hooks

  1. Modifying some aspect of the Nova operation
  2. Triggering an external action synchronously to some Nova operation
  3. Triggering an external action asynchronously to some Nova operation

The Rdo example is falling in scenario 1 since it is modifying the
injected files. I think this is is absolutely the kind of thing
we should explicitly *never* support. When external code can arbitrarily
modify some aspect of Nova operation we're in totally unchartered
territory as to the behaviour of Nova. To support that we'd need to
provide a stable internal API which is just not something we want to
tie ourselves into. I don't know just what the Rdo example is trying
to achieve, but whatever it is, it should be via some supportable API
and not a hook.,

Scenaris 2 and 3 are both valid to consider. Using the notifications
system gets as an asynchronous trigger mechanism, which is probably
fine for many scenarios.  The big question is whether there's a
compelling need for scenario two, where the external action blocks
execution of the Nova operation until it has completed its hook.


Even in the case of scenario two it is possible in some cases to use a 
proxy to intercept the HTTP request, take action, and then forward it 
or reject it as appropriate.


I think the real question is whether there's a need to trigger an 
external action synchronously from down in the guts of the nova code.


The hooks do the following: 
https://github.com/rcritten/rdo-vm-factory/blob/use-centos/rdo-ipa-nova/novahooks.py#L271


We need to generate a token (ipaotp) and call ipa host-add with that 
token _before_ the new machine has a chance to call ipa-client-install.  
We have to guarantee that the client cannot call ipa-client-install 
until we get back the response from ipa that the host has been added 
with the token.  Additionally, we store the token in an injected_file in 
the new machine, so the file can be removed as soon as possible.  We 
tried storing the token in the VM metadata, but there is apparently no 
way to delete it?  Can the machine do


curl -XDELETE http://168.254.169.254/openstack/latest/metadata?key=value ?

Using the build_instance.pre hook in Nova makes this simple and 
straightforward.  It's also relatively painless to use the 
network_info.post hook to handle the floating ip address assignment.


Is it possible to do the above using notifications without jumping 
through too many hoops?




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



__
OpenStack Development Mailing 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]Ports not binding correctly after restart

[Kevin Benton]

There was an issue with the order of the agents starting up that led to
some issues with L3 HA that was fixed with a systemd notification here:
https://review.openstack.org/#/c/254920/ However, I assume there had to be
a corresponding packaging patch that would make the the other agents wait
for that notification before starting.

I think a way to test if that would fix your issue is to restart the DHCP
agent and L3 agent and see if that fixes your broken resources.

On Mon, Feb 29, 2016 at 8:48 AM, Sergio Morales Acuña 
wrote:

> Hi all.
> I'm facing a problem with "Neutron/OVS/DVR" in "Liberty".
>
> With 3 network/compute nodes I created, successfully, 100 tenants, 100
> networks (1 per tenants), 3 DHCP agents per network and 100 routers (1 per
> network), 100 VM (1 per tenant) and 1 FIP per VM. All working and
> responding.
>
> The problem occurs after restarting the servers. Now i have some routers
> without communications, dhcp agents not connected to the tenant network and
> VM running but not connected to the router/fip. This happen randomly for
> any router/dhcp agent/ or VM.
>
> There's a way to force a port binding check in neutron? How i can make the
> restart process more effective?
>
> I'm using Neutron 7.0.1 (DVR), RHEL 7.2, Kolla with RDO Liberty and  OVS
> 2.3.2.
>
> I tried neutron 7.0.4 (from stable/libery) with OVS 2.3.2 and OVS 2.4.0.
>
> I would appreciate any comments, suggestions or patches under review.
>
> __
> OpenStack Development Mailing 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] Team meeting this Tue at 1400 UTC

[Ihar Hrachyshka]

Hi neutrinos,

A kind reminder for this week's meeting. More on the agenda [1].

Cheers,
Ihar

[1] https://wiki.openstack.org/wiki/Network/Meetings  
__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Chris Friesen]

On 02/29/2016 12:22 PM, Daniel P. Berrange wrote:


There's three core scenarios for hooks

  1. Modifying some aspect of the Nova operation
  2. Triggering an external action synchronously to some Nova operation
  3. Triggering an external action asynchronously to some Nova operation

The Rdo example is falling in scenario 1 since it is modifying the
injected files. I think this is is absolutely the kind of thing
we should explicitly *never* support. When external code can arbitrarily
modify some aspect of Nova operation we're in totally unchartered
territory as to the behaviour of Nova. To support that we'd need to
provide a stable internal API which is just not something we want to
tie ourselves into. I don't know just what the Rdo example is trying
to achieve, but whatever it is, it should be via some supportable API
and not a hook.,

Scenaris 2 and 3 are both valid to consider. Using the notifications
system gets as an asynchronous trigger mechanism, which is probably
fine for many scenarios.  The big question is whether there's a
compelling need for scenario two, where the external action blocks
execution of the Nova operation until it has completed its hook.


Even in the case of scenario two it is possible in some cases to use a proxy to 
intercept the HTTP request, take action, and then forward it or reject it as 
appropriate.


I think the real question is whether there's a need to trigger an external 
action synchronously from down in the guts of the nova code.


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] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/22/2016 10:49 AM, Daniel P. Berrange wrote:
> On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote:
>> Hi everyone,
>>
>> TL;DR: Let's split the events, starting after Barcelona.
> 
> Yes, please. Your proposal addresses the big issue I have with current
> summits which is the really poor timing wrt start of each dev cycle.
> 
>> The idea would be to split the events. The first event would be for upstream
>> technical contributors to OpenStack. It would be held in a simpler,
>> scaled-back setting that would let all OpenStack project teams meet in
>> separate rooms, but in a co-located event that would make it easy to have
>> ad-hoc cross-project discussions. It would happen closer to the centers of
>> mass of contributors, in less-expensive locations.
> 
> The idea that we can choose less expensive locations is great, but I'm a
> little wary of focusing too much on "centers of mass of contributors", as
> it can easily become an excuse to have it in roughly the same places each
> time. As a non-USA based contributor, I really value the fact the the
> summits rotate around different regions instead of spending all the time
> in the USA as was the case earlier in openstcck days. Minimizing travel
> costs is no doubt a welcome aim for companies' budgets, but it should not
> be allowed to dominate to such a large extent that we miss representation
> of different regions. ie if we never went back to Asia because the it is
> cheaper for the /current/ majority of contributors to go to the US, we'll
> make it harder to attract new contributors from those regions we avoid on
> cost ground. The "center of mass of contributors" could become a self-
> fullfilling prophecy.
> 
> IOW, I'm onboard with choosing less expensive locations, but would like
> to see us still make the effort to reach out across different regions
> for the events, and not become too US focused once again.

I agree with Dan here. Ensuring the events move around and go to
different contributors is very important in ensuring we hear new or
quiet voices.

I was surprised at the difference in how operators approach their
business in Europe as compared to the US and was glad to have the
experience to hear their voice. I would like to believe we have the
ability to continue to hold contributor events in different geographical
areas.

> 
>> The split should ideally reduce the needs to organize separate in-person
>> mid-cycle events. If some are still needed, the main conference venue and
>> time could easily be used to provide space for such midcycle events (given
>> that it would end up happening in the middle of the cycle).
> 
> The obvious risk with suggesting that current mid-cycle events could take
> place alongside the business conference, is that the "business conference"
> ends up being just as large as our combined conference is today.

I think the obstacles to listening at a large event, or co-located with
one, would be larger than any cost savings for using a spare room. The
trouble is it is hard to put a dollar amount on listening or an
environment that is conducive to listening.

My ability to listen is inversely proportional to the amount of people I
witness on any given day, regardless of whether they are in the room
with me or not. Smaller is better for my ability to listen.

Thank you,
Anita.

> IOW we
> risk actually creating 4 big official developer events a year, instead of
> the current 2 events + small unofficial mid-cycles. You'd need to find some
> way to limit the scope of any "mid cycle" events that co-located with the
> business conference to prevent it growing out of hand.  We really want to
> make sure we keep the mid-cycles portrayed as optional small scale
> "hackathons", and not something that contributors feel obligated to
> attend. IMHO they're already risking getting out of hand - it is hard to
> feel well connected to development plans if you miss the mid-cycle events.
> 
> Regards,
> Daniel
> 


__
OpenStack Development Mailing 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] core members for tripleo-ui

[James Slagle]

On Mon, Feb 29, 2016 at 12:32 PM, Ana Krivokapic  wrote:
> On Mon, Feb 29, 2016 at 4:27 PM, Dan Prince  wrote:
>> There is a new projects for the ui called tripleo-ui. As most of the
>> existing TripleO core members aren't going to be reviewing UI specific
>> patches is seems reasonable that we might add a few review candidates
>> who can focus specifically on UI specific patches.
>
> Thanks, I think this makes perfect sense!
>
>>
>> I'd like to proposed we add Jiri Tomasek and Ana Krivokapic as core
>> candidates that will focus primarily on the UI. They would be added to
>> tripleo core but would agree to only +2 patches within the UI for now,
>> or at least until they are re-nominated for more general TripleO core,
>> etc.
>
> I'd like to suggest Florian Fuchs instead of myself, as he has far
> more contributions (both commits and reviews) to the UI project (such
> as it is so far, [1]) then I do.
>
>>
>> Core members if you could please vote on this so we can add these
>> members at the close of this week. Thanks,

+1

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Ed Leafe]

On 02/29/2016 03:19 AM, Sylvain Bauza wrote:

>>> 3. Losing the main summit as an excuse to fund devs travel
>>>
>>> Some developers are sent to the Design Summit only because the main
>>> summit is happening at the same time and wouldn't get funding to attend
>>> a specific event.
>>
>> If you have to pretend to attend the Summit to be able to attend the
>> Design Summit instead, there is deception involved. I'd suggest to
>> have a frank talk with your employer on where the most value lies for
>> you in attending which event. We also have the Travel support program
>> to cover the gaps.
> 
> Well, not all companies are platinum or gold Foundation sponsors and
> some are contributing to OpenStack with very little budget commitment
> apart human resources.
> While one could claim the opportunity to ask their company to increase
> their budget, my guts is that the vast majority will just be unable to
> get that and will be veto'ed.

Other organizations, even the big names in sponsorship, have multiple
layers of management in which the people setting travel policy are not
the people leading the commitment to OpenStack (*cough*IBM*cough*). In
other words, travel to events is not counted as part of the business
support for OpenStack. So the issue doesn't only affect small companies
with tiny budgets.

-- 

-- Ed Leafe



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] [magnum] Discussion of supporting single/multiple OS distro

[Tim Bell]

From:  Adrian Otto
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
Date:  Monday 29 February 2016 at 19:36
To:  "OpenStack Development Mailing List (not for usage questions)"
Subject:  Re: [openstack-dev] [magnum] Discussion of supporting single/multiple 
OS distro

Consider this: Which OS runs on the bay nodes is not important to end users. 
What matters to users is the environments their containers execute in, which 
has only one thing in common with the bay node OS: the kernel. The linux 
syscall interface is stable enough that the various linux distributions can all 
run concurrently in neighboring containers sharing same kernel. There is really 
no material reason why the bay OS choice must match what distro the container 
is based on. Although I’m persuaded by Hongbin’s concern to mitigate risk of 
future changes WRT whatever OS distro is the prevailing one for bay nodes, 
there are a few items of concern about duality I’d like to zero in on: 

1) Participation from Magnum contributors to support the CoreOS specific 
template features has been weak in recent months. By comparison, participation 
relating to Fedora/Atomic have been much stronger.

2) Properly testing multiple bay node OS distros (would) significantly increase 
the run time and complexity of our functional tests.

3) Having support for multiple bay node OS choices requires more extensive 
documentation, and more comprehensive troubleshooting details.

If we proceed with just one supported disto for bay nodes, and offer 
extensibility points to allow alternates to be used in place of it, we should 
be able to address the risk concern of the chosen distro by selecting an 
alternate when that change is needed, by using those extensibility points. 
These include the ability to specify your own bay image, and the ability to use 
your own associated Heat template. 

There are potential operator implications if we limited the selection of 
supported distros for bay nodes too far.  

There is much that will go on to integrate with the centre’s automation tools 
to ensure the capacity in these nodes can be managed consistently (such as 
monitoring, alarming, QA cycles,...). I feel that supporting a Ubuntu flavor 
and a RHEL/CentOS/SL flavor would cover most scenarios. In any case, a plug in 
architecture is needed to support innovation but the baseline tests should 
cover the common use cases such as a RHEL and Ubuntu flavor.



I see value in risk mitigation, it may make sense to simplify in the short term 
and address that need when it becomes necessary. My point of view might be 
different if we had contributors willing and ready to address the variety of 
drawbacks that accompany the strategy of supporting multiple bay node OS 
choices. In absence of such a community interest, my preference is to simplify 
to increase our velocity. This seems to me to be a relatively easy way to 
reduce complexity around heat template versioning. What do you think?

Thanks,

Adrian

On Feb 29, 2016, at 8:40 AM, Hongbin Lu  wrote:

Hi team,
 
This is a continued discussion from a review [1]. Corey O'Brien suggested to 
have Magnum support a single OS distro (Atomic). I disagreed. I think we should 
bring the discussion to here to get broader set of inputs. 
 
Corey O'Brien
>From the midcycle, we decided we weren't going to continue to support 2 
>different versions of the k8s template. Instead, we were going to maintain the 
>Fedora Atomic version of k8s and remove the coreos templates from the tree. I 
>don't think we should continue to develop features for coreos k8s if that is 
>true.
In addition, I don't think we should break the coreos template by adding the 
trust token as a heat parameter.
 
Hongbin Lu
I was on the midcycle and I don't remember any decision to remove CoreOS 
support. Why you want to remove CoreOS templates from the tree. Please note 
that this is a very big decision and please discuss it with the team 
thoughtfully and make sure everyone agree.
 
Corey O'Brien
Removing the coreos templates was a part of the COE drivers decision. Since 
each COE driver will only support 1 distro+version+coe we discussed which ones 
to support in tree. The decision was that instead of trying to support every 
distro and every version for every coe, the magnum tree would only have support 
for 1 version of 1 distro for each of the 3 COEs (swarm/docker/mesos). Since we 
already are going to support Atomic for swarm, removing coreos and keeping 
Atomic for kubernetes was the favored choice.
 
Hongbin Lu
Strongly disagree. It is a huge risk to support a single distro. The selected 
distro could die in the future. Who knows. Why make Magnum take this huge risk? 
Again, the decision of supporting single distro is a very big decision. Please 
bring it up to the team and have it discuss thoughtfully before making any 
decision. Also, Magnum doesn't have to support every distro and every version 
for every coe, 

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

[Andrew Laski]

On Mon, Feb 29, 2016, at 01:18 PM, Dan Smith wrote:
> > Forgive my ignorance or for playing devil's advocate, but wouldn't the
> > main difference between notifications and hooks be that notifications
> > are asynchronous and hooks aren't?
> 
> The main difference is that notifications are external and intended to
> be stable (especially with the versioned notifications effort). The
> hooks are internal and depend wholly on internal data structures.
> 
> > In the case of how Rdo was using it,
> > they are adding things to the injected_files list before the instance is
> > created in the compute API.  You couldn't do that with notifications as
> > far as I know.
> 
> Nope, definitely not, but I see that as a good thing. Injecting files
> like that is likely to be very fragile and I think mostly regarded as
> substantially less desirable than the alternatives, regardless of how it
> happens.
> 
> I think that Laski's point was that the most useful and least dangerous
> thing that hooks can be used for is the use case that is much better
> served by notifications.

Yep. My experience with them was things like updating an external cache
on create/delete or calling out to a DNS provider to remove a reverse
DNS entry on instance delete. Things that could easily be handled with
notifications, and use cases that I think we should continue to support
by improving notifications if necessary.


> 
> So, if file injection (and any other internals-mangling that other
> people may use them for) is not a reason to keep hooks, and if
> notifications are the proper way to trigger on things happening, then
> there's no reason to keep hooks.
> 
> --Dan
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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][release] releases are not automatic, please check for review comments

[Doug Hellmann]

We have several release requests in the queue right now that have
comments and -1 votes asking for more details. Please check back if
you've filed a request so we don't miss the window to process the
request this week.

Doug

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

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

[Sean Dague]

On 02/29/2016 01:33 PM, Andrew Laski wrote:
> 
> 
> On Mon, Feb 29, 2016, at 12:53 PM, Rob Crittenden wrote:
>> Andrew Laski wrote:
>>>
>>>
>>> On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote:
> In our continued quest on being more explicit about plug points it feels
> like we should other document the interface (which means creating
> stability on the hook parameters) or we should deprecate this construct
> as part of a bygone era.
>
> I lean on deprecation because it feels like a thing we don't really want
> to support going forward, but I can go either way.

 Deprecate and remove, please. We've been removing these sorts of things
 over time, and nova hooks have been ignored in that process. But really,
 making them more rigid is going to get in the way over time, trying to
 continue to honor an interface that codifies internals at a certain
 point in time, and leaving them as-is will just continue to generate
 issues like the quoted bug.

 I don't "lean" on deprecation, I feel strongly that these should go away.
>>>
>>> I've worked on a deployment that uses them heavily and would be impacted
>>> by their removal. They are a very convenient place to put code that
>>> should run based on Nova events but I have yet to see a usage that
>>> couldn't have been implemented by having a service listen to
>>> notifications and run that same code. However there is no service that
>>> does this. So the only argument I can see for keeping them is that it's
>>> more convenient to put that code into Nova rather than implement
>>> something that listens for notifications. And that's not a convincing
>>> argument to me.
>>
>> The ability to inject files on a per-VM basis is one thing that would be
>> missing. Right now decisions can be made inside the hook using
>> attributes of the VM to decide whether and what to inject, including
>> files generated inside the hook itself.
>>
>> I won't argue that the API is nice, it isn't, but I'd prefer a replace
>> then deprecate model instead.
>>
>> I'm not entirely sure that the notifications contain all the same
>> information as is available now in the hooks.
> 
> This is something we can and should address if there is useful
> information missing from notifications.

100% agreed. I would consider that a priority feature for Newton if it
can be enumerated.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [kolla] unblocking the gate

[Clark Boylan]

On Mon, Feb 29, 2016, at 09:09 AM, Steven Dake (stdake) wrote:
> 
> 
> On 2/29/16, 12:26 AM, "Andreas Jaeger"  wrote:
> >This is not needed, the CI system always rebases if you run tests. To
> >get current tests, a simple "recheck" is enough.
> >
> >Also, we test in the gate before merging - again after rebasing to head.
> >That should take care of not merging anything broken. Running recheck
> >after a larger change will ensure that you have recent results.
> 
> Andreas,
> 
> Thanks for the recheck information.  I thought the gate ran against what
> it was submitted with as head.  We don't have any gate jobs at present
> (or
> many) they are mostly check jobs, so its pre-merge checking that we need
> folks to do.
> 
To clarify the check pipeline changes are merged into their target
branches before testing and the gate pipeline changes are merged into
the forward looking state of the world that Zuul generates as part of
gate testing. This means you do not need to rebase and create new
patchsets to get updated test results, just recheck.

You should only need to rebase and create a new patchset if a merge
conflict exists.

Clark

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

Re: [openstack-dev] [devstack] stack.sh keeps failing with RTNETLINK answers: Network is unreachable

[Brian Haley]

On 02/26/2016 03:48 AM, Paul Carlton wrote:

Sean

Don't think unstack failed, when I manually create the device ( sudo ovs-vsctl
--no-wait -- --may-exist add-br br-ex) unstack.sh removes it.

sudo ip route show
default via 172.18.20.1 dev eth0
169.254.169.254 via 172.18.20.2 dev eth0
172.18.20.0/24 dev eth0  proto kernel  scope link  src 172.18.20.23
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1


Matt

config attached


So getting back to your original error:

$ sudo ip route replace 10.1.0.0/20 via 192.168.100.200
RTNETLINK answers: Network is unreachable

Looking at your local.conf:

FIXED_RANGE=10.1.0.0/20
FLOATING_RANGE=192.168.100.0/24
Q_FLOATING_ALLOCATION_POOL=start=192.168.100.200,end=192.168.100.254
PUBLIC_NETWORK_GATEWAY=192.168.100.1
PUBLIC_BRIDGE=br-ex

The 'ip route replace...' above is adding a route for the fixed IP range you've 
specified for your private subnet via what should be the neutron router for the 
network.  That router was allocated .200 when it attached to the external 
subnet, which is fine.


In order for this to work, the IP $PUBLIC_NETWORK_GATEWAY (192.168.100.1) needs 
to have been configured on br-ex ($PUBLIC_BRIDGE) beforehand, since otherwise 
the network will be unreachable.  Does 'ip a s dev br-ex' show that IP?


It could be that some setting in your local.conf is causing some 
mis-configuration, pasting 'neutron port-list' and 'neutron subnet-list' might 
help track down what is wrong.


-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] [magnum] Discussion of supporting single/multiple OS distro

[Adrian Otto]

Consider this: Which OS runs on the bay nodes is not important to end users. 
What matters to users is the environments their containers execute in, which 
has only one thing in common with the bay node OS: the kernel. The linux 
syscall interface is stable enough that the various linux distributions can all 
run concurrently in neighboring containers sharing same kernel. There is really 
no material reason why the bay OS choice must match what distro the container 
is based on. Although I’m persuaded by Hongbin’s concern to mitigate risk of 
future changes WRT whatever OS distro is the prevailing one for bay nodes, 
there are a few items of concern about duality I’d like to zero in on:

1) Participation from Magnum contributors to support the CoreOS specific 
template features has been weak in recent months. By comparison, participation 
relating to Fedora/Atomic have been much stronger.

2) Properly testing multiple bay node OS distros (would) significantly increase 
the run time and complexity of our functional tests.

3) Having support for multiple bay node OS choices requires more extensive 
documentation, and more comprehensive troubleshooting details.

If we proceed with just one supported disto for bay nodes, and offer 
extensibility points to allow alternates to be used in place of it, we should 
be able to address the risk concern of the chosen distro by selecting an 
alternate when that change is needed, by using those extensibility points. 
These include the ability to specify your own bay image, and the ability to use 
your own associated Heat template.

I see value in risk mitigation, it may make sense to simplify in the short term 
and address that need when it becomes necessary. My point of view might be 
different if we had contributors willing and ready to address the variety of 
drawbacks that accompany the strategy of supporting multiple bay node OS 
choices. In absence of such a community interest, my preference is to simplify 
to increase our velocity. This seems to me to be a relatively easy way to 
reduce complexity around heat template versioning. What do you think?

Thanks,

Adrian

On Feb 29, 2016, at 8:40 AM, Hongbin Lu 
> wrote:

Hi team,

This is a continued discussion from a review [1]. Corey O'Brien suggested to 
have Magnum support a single OS distro (Atomic). I disagreed. I think we should 
bring the discussion to here to get broader set of inputs.

Corey O'Brien
From the midcycle, we decided we weren't going to continue to support 2 
different versions of the k8s template. Instead, we were going to maintain the 
Fedora Atomic version of k8s and remove the coreos templates from the tree. I 
don't think we should continue to develop features for coreos k8s if that is 
true.
In addition, I don't think we should break the coreos template by adding the 
trust token as a heat parameter.

Hongbin Lu
I was on the midcycle and I don't remember any decision to remove CoreOS 
support. Why you want to remove CoreOS templates from the tree. Please note 
that this is a very big decision and please discuss it with the team 
thoughtfully and make sure everyone agree.

Corey O'Brien
Removing the coreos templates was a part of the COE drivers decision. Since 
each COE driver will only support 1 distro+version+coe we discussed which ones 
to support in tree. The decision was that instead of trying to support every 
distro and every version for every coe, the magnum tree would only have support 
for 1 version of 1 distro for each of the 3 COEs (swarm/docker/mesos). Since we 
already are going to support Atomic for swarm, removing coreos and keeping 
Atomic for kubernetes was the favored choice.

Hongbin Lu
Strongly disagree. It is a huge risk to support a single distro. The selected 
distro could die in the future. Who knows. Why make Magnum take this huge risk? 
Again, the decision of supporting single distro is a very big decision. Please 
bring it up to the team and have it discuss thoughtfully before making any 
decision. Also, Magnum doesn't have to support every distro and every version 
for every coe, but should support *more than one* popular distro for some COEs 
(especially for the popular COEs).

Corey O'Brien
The discussion at the midcycle started from the idea of adding support for RHEL 
and CentOS. We all discussed and decided that we wouldn't try to support 
everything in tree. Magnum would provide support in-tree for 1 per COE and the 
COE driver interface would allow others to add support for their preferred 
distro out of tree.

Hongbin Lu
I agreed the part that "we wouldn't try to support everything in tree". That 
doesn't imply the decision to support single distro. Again, support single 
distro is a huge risk. Why make Magnum take this huge risk?

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

Best regards,
Hongbin
__
OpenStack Development Mailing 

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

[Andrew Laski]

On Mon, Feb 29, 2016, at 12:53 PM, Rob Crittenden wrote:
> Andrew Laski wrote:
> > 
> > 
> > On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote:
> >>> In our continued quest on being more explicit about plug points it feels
> >>> like we should other document the interface (which means creating
> >>> stability on the hook parameters) or we should deprecate this construct
> >>> as part of a bygone era.
> >>>
> >>> I lean on deprecation because it feels like a thing we don't really want
> >>> to support going forward, but I can go either way.
> >>
> >> Deprecate and remove, please. We've been removing these sorts of things
> >> over time, and nova hooks have been ignored in that process. But really,
> >> making them more rigid is going to get in the way over time, trying to
> >> continue to honor an interface that codifies internals at a certain
> >> point in time, and leaving them as-is will just continue to generate
> >> issues like the quoted bug.
> >>
> >> I don't "lean" on deprecation, I feel strongly that these should go away.
> > 
> > I've worked on a deployment that uses them heavily and would be impacted
> > by their removal. They are a very convenient place to put code that
> > should run based on Nova events but I have yet to see a usage that
> > couldn't have been implemented by having a service listen to
> > notifications and run that same code. However there is no service that
> > does this. So the only argument I can see for keeping them is that it's
> > more convenient to put that code into Nova rather than implement
> > something that listens for notifications. And that's not a convincing
> > argument to me.
> 
> The ability to inject files on a per-VM basis is one thing that would be
> missing. Right now decisions can be made inside the hook using
> attributes of the VM to decide whether and what to inject, including
> files generated inside the hook itself.
> 
> I won't argue that the API is nice, it isn't, but I'd prefer a replace
> then deprecate model instead.
> 
> I'm not entirely sure that the notifications contain all the same
> information as is available now in the hooks.

This is something we can and should address if there is useful
information missing from notifications.

> 
> rob
> 
> > So I agree with moving forward on deprecation and think that
> > notifications provide a suitable replacement for the functionality
> > provided.
> > 
> > 
> >>
> >> --Dan
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > __
> > OpenStack Development Mailing 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] [nova] nova hooks - document & test or deprecate?

[Daniel P. Berrange]

On Mon, Feb 29, 2016 at 12:03:00PM -0600, Matt Riedemann wrote:
> 
> 
> On 2/29/2016 11:23 AM, Andrew Laski wrote:
> >
> >
> >On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote:
> >>>In our continued quest on being more explicit about plug points it feels
> >>>like we should other document the interface (which means creating
> >>>stability on the hook parameters) or we should deprecate this construct
> >>>as part of a bygone era.
> >>>
> >>>I lean on deprecation because it feels like a thing we don't really want
> >>>to support going forward, but I can go either way.
> >>
> >>Deprecate and remove, please. We've been removing these sorts of things
> >>over time, and nova hooks have been ignored in that process. But really,
> >>making them more rigid is going to get in the way over time, trying to
> >>continue to honor an interface that codifies internals at a certain
> >>point in time, and leaving them as-is will just continue to generate
> >>issues like the quoted bug.
> >>
> >>I don't "lean" on deprecation, I feel strongly that these should go away.
> >
> >I've worked on a deployment that uses them heavily and would be impacted
> >by their removal. They are a very convenient place to put code that
> >should run based on Nova events but I have yet to see a usage that
> >couldn't have been implemented by having a service listen to
> >notifications and run that same code. However there is no service that
> >does this. So the only argument I can see for keeping them is that it's
> >more convenient to put that code into Nova rather than implement
> >something that listens for notifications. And that's not a convincing
> >argument to me.
> >
> >So I agree with moving forward on deprecation and think that
> >notifications provide a suitable replacement for the functionality
> >provided.
> 
> Forgive my ignorance or for playing devil's advocate, but wouldn't the main
> difference between notifications and hooks be that notifications are
> asynchronous and hooks aren't?  In the case of how Rdo was using it, they
> are adding things to the injected_files list before the instance is created
> in the compute API.  You couldn't do that with notifications as far as I
> know.

Sure, notifications do *not* replace all possible use case of the current
hooks, but I think that is actually desirable.

There's three core scenarios for hooks

 1. Modifying some aspect of the Nova operation
 2. Triggering an external action synchronously to some Nova operation
 3. Triggering an external action asynchronously to some Nova operation

The Rdo example is falling in scenario 1 since it is modifying the
injected files. I think this is is absolutely the kind of thing
we should explicitly *never* support. When external code can arbitrarily
modify some aspect of Nova operation we're in totally unchartered
territory as to the behaviour of Nova. To support that we'd need to
provide a stable internal API which is just not something we want to
tie ourselves into. I don't know just what the Rdo example is trying
to achieve, but whatever it is, it should be via some supportable API
and not a hook.,

Scenaris 2 and 3 are both valid to consider. Using the notifications
system gets as an asynchronous trigger mechanism, which is probably
fine for many scenarios.  The big question is whether there's a
compelling need for scenario two, where the external action blocks
execution of the Nova operation until it has completed its hook.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Dan Smith]

> Forgive my ignorance or for playing devil's advocate, but wouldn't the
> main difference between notifications and hooks be that notifications
> are asynchronous and hooks aren't?

The main difference is that notifications are external and intended to
be stable (especially with the versioned notifications effort). The
hooks are internal and depend wholly on internal data structures.

> In the case of how Rdo was using it,
> they are adding things to the injected_files list before the instance is
> created in the compute API.  You couldn't do that with notifications as
> far as I know.

Nope, definitely not, but I see that as a good thing. Injecting files
like that is likely to be very fragile and I think mostly regarded as
substantially less desirable than the alternatives, regardless of how it
happens.

I think that Laski's point was that the most useful and least dangerous
thing that hooks can be used for is the use case that is much better
served by notifications.

So, if file injection (and any other internals-mangling that other
people may use them for) is not a reason to keep hooks, and if
notifications are the proper way to trigger on things happening, then
there's no reason to keep hooks.

--Dan

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/22/2016 12:35 PM, Thierry Carrez wrote:
> Clayton O'Neill wrote:
>> Is the expectation that the ops mid-cycle would continue separately,
>> or be held with the meeting formerly known as the Design Summit?
>>
>> Personally I’d prefer they be held together, but scheduled with the
>> thought that operators aren’t likely to be interested in work
>> sessions, but that a good number of us would be interested in
>> cross-project and some project specific planning sessions.  This would
>> also open up the possibility of having some sessions specific intended
>> for operator/developer feedback sessions.
> 
> I'll let Tom comment on that, but the general idea in the strawman
> proposal was that the Ops "midcycle" event would be preserved as a
> separate event, but likely turn more and more regional to maximize local
> attendance. The rationale was that it's hard for ops to justify
> traveling to a contributors-branded event, while they can more easily
> justify going to the main OpenStack Summit user conference event, and to
> regional Ops gatherings.
> 
> But things are still pretty open on that front, so let's see what the
> feedback is.
> 

We actually had a good chat about one recognized event vs. regional
events at the feedback session at the Ops Meetup in Manchester.

https://etherpad.openstack.org/p/MAN-ops-feedback

I'm speaking up here because I chaired the session, I'm open to
correction on my points from Tom or other Ops folks in attendance.

The benefit of having one recognized event in Manchester is that folks
came to attend from all over the world. We had people from Australia,
China, Japan, Africa, all over Europe, Canada and the US. Having one
moving recognized event means that some folks can only attend every few
years rather than every release, however the benefit is that when the
event is in your geographical region you have folks from other places
coming to you. This cross-pollination would be lost if regional events
replaced one recognized event.

If we call the one recognized Ops event per release one name, currently
it is Meetup: https://wiki.openstack.org/wiki/Operations/Meetups then
there is nothing standing in the way of folks having other local events
if they want to set them up. Currently OpenStack Days are the
acknowledged local event which brings together operators, devs, users
and any other interested audience who might get some benefit from
OpenStack Days.

https://www.openstack.org/community/events/openstackdays?awesm=awe.sm_xkBj

A region could have as many OpenStack Days as they wish (as far as I
understand it) which would satisfy some "gathering-per-release" criteria
for some folks while ensuring one geographically moving recognized event
happened for operators so the benefit from global focus still happens.

Thank you,
Anita.

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

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

[Matt Riedemann]

On 2/29/2016 11:23 AM, Andrew Laski wrote:



On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote:

In our continued quest on being more explicit about plug points it feels
like we should other document the interface (which means creating
stability on the hook parameters) or we should deprecate this construct
as part of a bygone era.

I lean on deprecation because it feels like a thing we don't really want
to support going forward, but I can go either way.


Deprecate and remove, please. We've been removing these sorts of things
over time, and nova hooks have been ignored in that process. But really,
making them more rigid is going to get in the way over time, trying to
continue to honor an interface that codifies internals at a certain
point in time, and leaving them as-is will just continue to generate
issues like the quoted bug.

I don't "lean" on deprecation, I feel strongly that these should go away.


I've worked on a deployment that uses them heavily and would be impacted
by their removal. They are a very convenient place to put code that
should run based on Nova events but I have yet to see a usage that
couldn't have been implemented by having a service listen to
notifications and run that same code. However there is no service that
does this. So the only argument I can see for keeping them is that it's
more convenient to put that code into Nova rather than implement
something that listens for notifications. And that's not a convincing
argument to me.

So I agree with moving forward on deprecation and think that
notifications provide a suitable replacement for the functionality
provided.




--Dan

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


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



Forgive my ignorance or for playing devil's advocate, but wouldn't the 
main difference between notifications and hooks be that notifications 
are asynchronous and hooks aren't?  In the case of how Rdo was using it, 
they are adding things to the injected_files list before the instance is 
created in the compute API.  You couldn't do that with notifications as 
far as I know.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/23/2016 04:26 AM, Thierry Carrez wrote:
> Tim Bell wrote:
>> On 22/02/16 17:27, "John Garbutt"  wrote:
>>> [...]
>>> I am sure there are more questions that will pop up. Like I assume
>>> this means there is no ATC free pass to the summit? And I guess a
>>> small nominal fee for the contributor meetup (like the recent ops
>>> meetup, to help predict numbers of accurately)? I guess that helps
>>> level the playing field for contributors who don't put git commits in
>>> the repo (I am thinking vocal operators that don't contribute code).
>>> But I probably shouldn't go into all that just yet.
>>
>> I would like to find a way to allow contributors cheaper access to the
>> summits. Many of the devOPS contributors are patching test cases,
>> configuration management recipes and documentation which should be
>> rewarded in some form.
>>
>> Assuming that many of the ATCs are not so motivated to attend the
>> summit, the cost in offering access to the event would not be
>> significant.
>>
>> Charging for the Ops meetups was, to my understanding, more to confirm
>> commitment to attend given limited space.
>>
>> Thus, I would be in favour of a preferential rate for contributors
>> (whether ATC is the right criteria is a different question) for summits.
> 
> Current thinking would be to give preferential rates to access the main
> summit to people who are present to other events (like this new
> separated contributors-oriented event, or Ops midcycle(s)). That would
> allow for a wider definition of "active community member" and reduce
> gaming.
> 

I think reducing gaming is important. It is valuable to include those
folks who wish to make a contribution to OpenStack, I have confidence
the next iteration of entry structure will try to more accurately
identify those folks who bring value to OpenStack.

Thank you,
Anita.

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

[openstack-dev] [Infra] Meeting Tuesday March 1st at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday March 1st, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting (2 weeks ago) are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-02-16-19.03.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-02-16-19.03.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-02-16-19.03.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing 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] A proposal to separate the design summit

[Anita Kuno]

On 02/22/2016 06:49 PM, Matt Fischer wrote:
> On Mon, Feb 22, 2016 at 11:51 AM, Tim Bell  wrote:
> 
>>
>>
>>
>>
>>
>> On 22/02/16 17:27, "John Garbutt"  wrote:
>>
>>> On 22 February 2016 at 15:31, Monty Taylor  wrote:
 On 02/22/2016 07:24 AM, Russell Bryant wrote:
> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez <
>> thie...@openstack.org
>> > wrote:
>> Hi everyone,
>> TL;DR: Let's split the events, starting after Barcelona.
> This proposal sounds fantastic.  Thank you very much to those that help
> put it together.
 Totally agree. I think it's an excellent way to address the concerns and
 balance all of the diverse needs we have.
>>>
>>> tl;dr
>>> +1
>>> Awesome work ttx.
>>> Thank you!
>>>
>>> Cheaper cities & venues should make it easier for more contributors to
>>> attend. Thats a big deal. This also feels like enough notice to plan
>>> for that.
>>>
>>> I think this means summit talk proposal deadline is both after the
>>> previous release, and after the contributor event for the next
>>> release? That should help keep proposals concrete (less guess work
>>> when submitting). Nice.
>>>
>>> Dev wise, it seems equally good timing. Initially I was worried about
>>> the event distracting from RC bugs, but actually I can see this
>>> helping.
>>>
>>> I am sure there are more questions that will pop up. Like I assume
>>> this means there is no ATC free pass to the summit? And I guess a
>>> small nominal fee for the contributor meetup (like the recent ops
>>> meetup, to help predict numbers of accurately)? I guess that helps
>>> level the playing field for contributors who don't put git commits in
>>> the repo (I am thinking vocal operators that don't contribute code).
>>> But I probably shouldn't go into all that just yet.
>>
>> I would like to find a way to allow contributors cheaper access to the
>> summits. Many of the devOPS contributors are patching test cases,
>> configuration management recipes and documentation which should be rewarded
>> in some form.
>>
>> Assuming that many of the ATCs are not so motivated to attend the summit,
>> the cost in offering access to the event would not be significant.
>>
>> Charging for the Ops meetups was, to my understanding, more to confirm
>> commitment to attend given limited space.
>>
>> Thus, I would be in favour of a preferential rate for contributors
>> (whether ATC is the right criteria is a different question) for summits.
>>
>>
>> Tim
> 
> 
> I believe this is already the case. Unless I'm mistaken contributing to a
> big tent config management project like the openstack puppet modules or
> chef counts for ATC. I'm not sure if osad is big tent but if so it would
> also count. Test cases and Docs also already count.

Contributions to any project listed in this file counts toward ATC
status:
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

Thank you,
Anita.

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


__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Rob Crittenden]

Andrew Laski wrote:
> 
> 
> On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote:
>>> In our continued quest on being more explicit about plug points it feels
>>> like we should other document the interface (which means creating
>>> stability on the hook parameters) or we should deprecate this construct
>>> as part of a bygone era.
>>>
>>> I lean on deprecation because it feels like a thing we don't really want
>>> to support going forward, but I can go either way.
>>
>> Deprecate and remove, please. We've been removing these sorts of things
>> over time, and nova hooks have been ignored in that process. But really,
>> making them more rigid is going to get in the way over time, trying to
>> continue to honor an interface that codifies internals at a certain
>> point in time, and leaving them as-is will just continue to generate
>> issues like the quoted bug.
>>
>> I don't "lean" on deprecation, I feel strongly that these should go away.
> 
> I've worked on a deployment that uses them heavily and would be impacted
> by their removal. They are a very convenient place to put code that
> should run based on Nova events but I have yet to see a usage that
> couldn't have been implemented by having a service listen to
> notifications and run that same code. However there is no service that
> does this. So the only argument I can see for keeping them is that it's
> more convenient to put that code into Nova rather than implement
> something that listens for notifications. And that's not a convincing
> argument to me.

The ability to inject files on a per-VM basis is one thing that would be
missing. Right now decisions can be made inside the hook using
attributes of the VM to decide whether and what to inject, including
files generated inside the hook itself.

I won't argue that the API is nice, it isn't, but I'd prefer a replace
then deprecate model instead.

I'm not entirely sure that the notifications contain all the same
information as is available now in the hooks.

rob

> So I agree with moving forward on deprecation and think that
> notifications provide a suitable replacement for the functionality
> provided.
> 
> 
>>
>> --Dan
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [all] audience for release notes

[Thomas Goirand]

On 02/29/2016 10:31 PM, Doug Hellmann wrote:
>>> Give this a try and see if it works any better:
>>> https://review.openstack.org/285812
>>
>> Oh, thanks so much! I'll try and give feedback on review.d.o. Is the
>> issue around the (missed) use of --debug-quick-random?
>>
>> Why do we need Reno unit tests to generate so many GPG keys btw, why not
>> just one or 2?
> 
> As you've noticed, reno scans the history of a git repository to find
> release notes. It doesn't actually read any of the files from the work
> tree. So for tests, we need to create a little git repo and then tag
> commits to look like releases. We do that for a bunch of scenarios, and
> each test case generates a GPG key to use for signing the tags.

The patch works super well, and I uploaded a new version of the Debian
package with unit tests at build time.

However, the combined output of gnupg and testr is a bit ugly. Wouldn't
it be nicer to just generate a single GPG key, reused by multiple tests,
using a unit test fixture?

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing 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] A proposal to separate the design summit

[Anita Kuno]

On 02/22/2016 11:06 AM, Dmitry Tantsur wrote:
> I agree with Daniel + a couple more comments inline.
> 
> On 02/22/2016 04:49 PM, Daniel P. Berrange wrote:
>> On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote:
>>> Hi everyone,
>>>
>>> TL;DR: Let's split the events, starting after Barcelona.
>>
>> Yes, please. Your proposal addresses the big issue I have with current
>> summits which is the really poor timing wrt start of each dev cycle.
>>
>>> The idea would be to split the events. The first event would be for
>>> upstream
>>> technical contributors to OpenStack. It would be held in a simpler,
>>> scaled-back setting that would let all OpenStack project teams meet in
>>> separate rooms, but in a co-located event that would make it easy to
>>> have
>>> ad-hoc cross-project discussions. It would happen closer to the
>>> centers of
>>> mass of contributors, in less-expensive locations.
>>
>> The idea that we can choose less expensive locations is great, but I'm a
>> little wary of focusing too much on "centers of mass of contributors", as
>> it can easily become an excuse to have it in roughly the same places each
>> time. As a non-USA based contributor, I really value the fact the the
>> summits rotate around different regions instead of spending all the time
>> in the USA as was the case earlier in openstcck days. Minimizing travel
>> costs is no doubt a welcome aim for companies' budgets, but it should not
>> be allowed to dominate to such a large extent that we miss representation
>> of different regions. ie if we never went back to Asia because the it is
>> cheaper for the /current/ majority of contributors to go to the US, we'll
>> make it harder to attract new contributors from those regions we avoid on
>> cost ground. The "center of mass of contributors" could become a self-
>> fullfilling prophecy.
>>
>> IOW, I'm onboard with choosing less expensive locations, but would like
>> to see us still make the effort to reach out across different regions
>> for the events, and not become too US focused once again.
> 
> +1 here. I got an impression that midcycles now usually happen in the
> US.

Anyone can view where sprints are held by looking at the sprints page:
https://wiki.openstack.org/wiki/Sprints

As far as stats for non-US based sprints:

Juno sprints: 2/12 outside the US
Kilo sprints: 2/18 outside the US
Liberty sprints: 1/21 outside the US
Mitaka sprints: 7/23 outside the US (two scheduled, yet to complete)

I would attribute having the Ops Meetup in the UK to having two other
events in the UK, Storyboard and the Product WG. Some events have the
ability to affect the location of other events.

As far as diversity (having events outside of the US) we seem to be
improving, so that is heartening to see. I do hope the trend continues.

Thank you,
Anita.

> Indeed, it's probably much cheaper for the majority of contributors,
> but would make things worse for non-US folks.
> 
>>
>>> The split should ideally reduce the needs to organize separate in-person
>>> mid-cycle events. If some are still needed, the main conference venue
>>> and
>>> time could easily be used to provide space for such midcycle events
>>> (given
>>> that it would end up happening in the middle of the cycle).
>>
>> The obvious risk with suggesting that current mid-cycle events could take
>> place alongside the business conference, is that the "business
>> conference"
>> ends up being just as large as our combined conference is today. IOW we
>> risk actually creating 4 big official developer events a year, instead of
>> the current 2 events + small unofficial mid-cycles. You'd need to find
>> some
>> way to limit the scope of any "mid cycle" events that co-located with the
>> business conference to prevent it growing out of hand.  We really want to
>> make sure we keep the mid-cycles portrayed as optional small scale
>> "hackathons", and not something that contributors feel obligated to
>> attend. IMHO they're already risking getting out of hand - it is hard to
>> feel well connected to development plans if you miss the mid-cycle
>> events.
> 
> This time we (Ironic) tried a virtual midcycle using the asterisk
> infrastructure provided by the infra team, and it worked surprisingly
> well. I'd recommend more teams trying this option instead of trying to
> find a better way of having one more expensive f2f event (even though I
> really like to meet other folks).
> 
>>
>> Regards,
>> Daniel
>>
> 
> 
> __
> OpenStack Development Mailing 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

[openstack-dev] [freezer] Freezer midclycle meetup

[Mathieu, Pierre-Arthur]

Hi,

The Freezer team is excited to announce that we're hosting our midcycle meetup 
on 15th and 16th of March, 2016.
The event is free and will happen in Galway, Ireland and be hosted by Hewlett 
Packard Enterprise.

Logistic is being managed here: 
https://etherpad.openstack.org/p/freezer_midcycle_meetup

Feel free to ask any question in this thread or in #openstack-freezer .

We hope to see you there,
Best Wishes,

Pierre

__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Daniel P. Berrange]

On Mon, Feb 29, 2016 at 12:23:09PM -0500, Andrew Laski wrote:
> 
> 
> On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote:
> > > In our continued quest on being more explicit about plug points it feels
> > > like we should other document the interface (which means creating
> > > stability on the hook parameters) or we should deprecate this construct
> > > as part of a bygone era.
> > > 
> > > I lean on deprecation because it feels like a thing we don't really want
> > > to support going forward, but I can go either way.
> > 
> > Deprecate and remove, please. We've been removing these sorts of things
> > over time, and nova hooks have been ignored in that process. But really,
> > making them more rigid is going to get in the way over time, trying to
> > continue to honor an interface that codifies internals at a certain
> > point in time, and leaving them as-is will just continue to generate
> > issues like the quoted bug.
> > 
> > I don't "lean" on deprecation, I feel strongly that these should go away.
> 
> I've worked on a deployment that uses them heavily and would be impacted
> by their removal. They are a very convenient place to put code that
> should run based on Nova events but I have yet to see a usage that
> couldn't have been implemented by having a service listen to
> notifications and run that same code. However there is no service that
> does this. So the only argument I can see for keeping them is that it's
> more convenient to put that code into Nova rather than implement
> something that listens for notifications. And that's not a convincing
> argument to me.

Yes, that's a prime example of a use case where we should be offering
a formally supportable solution instead of an unreliable hack using
hooks.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] core members for tripleo-ui

[Ana Krivokapic]

On Mon, Feb 29, 2016 at 4:27 PM, Dan Prince  wrote:
> There is a new projects for the ui called tripleo-ui. As most of the
> existing TripleO core members aren't going to be reviewing UI specific
> patches is seems reasonable that we might add a few review candidates
> who can focus specifically on UI specific patches.

Thanks, I think this makes perfect sense!

>
> I'd like to proposed we add Jiri Tomasek and Ana Krivokapic as core
> candidates that will focus primarily on the UI. They would be added to
> tripleo core but would agree to only +2 patches within the UI for now,
> or at least until they are re-nominated for more general TripleO core,
> etc.

I'd like to suggest Florian Fuchs instead of myself, as he has far
more contributions (both commits and reviews) to the UI project (such
as it is so far, [1]) then I do.

>
> Core members if you could please vote on this so we can add these
> members at the close of this week. Thanks,
>
> Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[1] https://github.com/rdo-management/rdo-director-ui/graphs/contributors

-- 
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] [all] A proposal to separate the design summit

[Thomas Goirand]

On 02/26/2016 10:13 PM, Tom Fifield wrote:
> 
> 
> On 26/02/16 22:02, Thomas Goirand wrote:
>> On 02/23/2016 12:33 AM, Jay Pipes wrote:
>>> OpenStack Conference <-- The main event.
>>> OpenStack:How <-- The developer planning event.
>>>
>>> :)
>>>
>>> -jay
>>
>> Probably I'm dumb, but I still don't understand what's wrong with the
>> name "design summit" for the developer planning event.
>>
>> Like most free software, OpenStack is a do-o-cracy where one must do the
>> things to make them happen. Sure, we do listen to our users, but the
>> design summit is actually where decisions are taken, like it or not...
> 
> "Implementation" decisions, yup. However, because of the position in the
> start of the planning stage of the cycle, the "design" decisions will
> happen at the main event, where we've got the users to give input.

Meaning that there would be not one, but 2 events where developers would
need to go? I don't think this will happen (too expensive).

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Andrew Laski]

On Mon, Feb 29, 2016, at 12:12 PM, Dan Smith wrote:
> > In our continued quest on being more explicit about plug points it feels
> > like we should other document the interface (which means creating
> > stability on the hook parameters) or we should deprecate this construct
> > as part of a bygone era.
> > 
> > I lean on deprecation because it feels like a thing we don't really want
> > to support going forward, but I can go either way.
> 
> Deprecate and remove, please. We've been removing these sorts of things
> over time, and nova hooks have been ignored in that process. But really,
> making them more rigid is going to get in the way over time, trying to
> continue to honor an interface that codifies internals at a certain
> point in time, and leaving them as-is will just continue to generate
> issues like the quoted bug.
> 
> I don't "lean" on deprecation, I feel strongly that these should go away.

I've worked on a deployment that uses them heavily and would be impacted
by their removal. They are a very convenient place to put code that
should run based on Nova events but I have yet to see a usage that
couldn't have been implemented by having a service listen to
notifications and run that same code. However there is no service that
does this. So the only argument I can see for keeping them is that it's
more convenient to put that code into Nova rather than implement
something that listens for notifications. And that's not a convincing
argument to me.

So I agree with moving forward on deprecation and think that
notifications provide a suitable replacement for the functionality
provided.


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

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

[openstack-dev] [Fuel][FFE] API must allow VIP to be manually set to ANY valid IP address

[Artem Roma]

Colleagues,
I would like to request a feature freeze exception for 'API must allow VIP
to be manually set to ANY valid IP address' [1].

There are three patches still under the review process [2][3][4].

[2][3] are blocked by merge freeze for UI changes due to separation of
fuel-ui and fuel-web repositories.

[4] introduces fix for old tech debt issue and blocked by corresponding
issue in cluster upgrade code. That needs to be addressed properly too in
the scope of the feature.

To merge the changes we need at most one week of time.

​[1]: ​https://blueprints.launchpad.net/fuel/+spec/allow-any-vip
[2]: https://review.openstack.org/#/c/286046/
[3]: https://review.openstack.org/#/c/285297/
[4]: https://review.openstack.org/#/c/284841/

-- 
Regards!)
__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Daniel P. Berrange]

On Mon, Feb 29, 2016 at 11:59:06AM -0500, Sean Dague wrote:
> The nova/hooks.py infrastructure has been with us since early Nova. It's
> currently only annotated on a few locations - 'build_instance',
> 'create_instance', 'delete_instance', and 'instance_network_info'. It's
> got a couple of unit tests on it, but nothing that actually tests real
> behavior of the hooks we have specified.
> 
> It does get used in the wild, and we do break it with changes we didn't
> ever anticipate would impact it -
> https://bugs.launchpad.net/nova/+bug/1518321
> 
> However, when you look into how that is used, it's really really odd and
> fragile -
> https://github.com/richm/rdo-vm-factory/blob/master/rdo-ipa-nova/novahooks.py#L248
> 
> 
> def pre(self, *args, **kwargs):
> # args[7] is the injected_files parameter array
> # the value is ('filename', 'base64 encoded contents')
> ipaotp = str(uuid.uuid4())
> ipainject = ('/tmp/ipaotp', base64.b64encode(ipaotp))
> args[7].extend(self.inject_files)
> args[7].append(ipainject)
> 
> In our continued quest on being more explicit about plug points it feels
> like we should other document the interface (which means creating
> stability on the hook parameters) or we should deprecate this construct
> as part of a bygone era.
> 
> I lean on deprecation because it feels like a thing we don't really want
> to support going forward, but I can go either way.

As it is designed, I think the hooks mechanism is really unsupportable
long term. It is exposing users to arbitrary internal Nova data structures
which we have changed at will and we cannot possibly ever consider them
to be a stable consumable API. I'm rather surprised we've not seen more
bugs like the one you've shown above - most likely thats a reflection
on not many people actually using this facility.

I'd be strongly in favour of deprecation & removal of this hooking
mechanism, as its unsupportable in any sane manner when it exposes
code to our internal unstable API & object model.

If there's stuff people are doing in hooks that's impossible any other
way, we should really be looking at what we need to provide in our
public API to achieve the same goal, if it is use case we wish to be
able to support.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] nova hooks - document & test or deprecate?

[Juan Antonio Osorio]

Well,

I do feel that the hooks have been pretty painful (having tried to use them
and
having stumbled upon that bug). However, even as undocumented as they were,
that seems to be the only way of doing actions in nova when instances are
spawned or deleted, while also having some awareness of what's given to the
instance. So we would need a replacement.

BR

On Mon, Feb 29, 2016 at 7:12 PM, Dan Smith  wrote:

> > In our continued quest on being more explicit about plug points it feels
> > like we should other document the interface (which means creating
> > stability on the hook parameters) or we should deprecate this construct
> > as part of a bygone era.
> >
> > I lean on deprecation because it feels like a thing we don't really want
> > to support going forward, but I can go either way.
>
> Deprecate and remove, please. We've been removing these sorts of things
> over time, and nova hooks have been ignored in that process. But really,
> making them more rigid is going to get in the way over time, trying to
> continue to honor an interface that codifies internals at a certain
> point in time, and leaving them as-is will just continue to generate
> issues like the quoted bug.
>
> I don't "lean" on deprecation, I feel strongly that these should go away.
>
> --Dan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

[Dmitry Teselkin]

I'd like to ask for a feature freeze exception for switching to CentOS-7.2
feature [0].

CentOS-7.2 ISO's have been tested periodically since the beginning of the
year, and all major issues were addressed / fixed at the moment. During the
last weekend I've made 70 BVT runs to verify that the  solution [2] for the
last issue - e1000 transmit unit hangs works. And it works, 0 tests of 35
failed [3].

Benefits of switching to CentOS-7.2 are quite obvious - we will return to
latest supported CentOS release, will fix a lot of bugs / security issues
[4] and will make further updates easier.

Risk of regression still exists, but it's quite low, 35 successful BVTs
can't be wrong.

To finish that feature the following should be done:
* review and merge e1000 workaround [2]
* review and merge spec [0]
* review and merge request that switches build CI to CentOS-7.2 [5]

I expect the last day it could be done is March, 4.

[0] https://review.openstack.org/#/c/280338/
[1] https://bugs.launchpad.net/fuel/+bug/1526544
[2] https://review.openstack.org/#/c/285306/
[3] https://etherpad.openstack.org/p/r.1c4cfee8185326d6922d6c9321404350
[4] https://etherpad.openstack.org/p/r.a7fe0b575d891ed81206765fa5be6630
[5] https://review.fuel-infra.org/#/c/17400/


-- 
Thanks,
Dmitry Teselkin
Mirantis
http://www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

[Dan Smith]

> In our continued quest on being more explicit about plug points it feels
> like we should other document the interface (which means creating
> stability on the hook parameters) or we should deprecate this construct
> as part of a bygone era.
> 
> I lean on deprecation because it feels like a thing we don't really want
> to support going forward, but I can go either way.

Deprecate and remove, please. We've been removing these sorts of things
over time, and nova hooks have been ignored in that process. But really,
making them more rigid is going to get in the way over time, trying to
continue to honor an interface that codifies internals at a certain
point in time, and leaving them as-is will just continue to generate
issues like the quoted bug.

I don't "lean" on deprecation, I feel strongly that these should go away.

--Dan

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

Re: [openstack-dev] [kolla] unblocking the gate

[Steven Dake (stdake)]

On 2/29/16, 12:26 AM, "Andreas Jaeger"  wrote:

>On 2016-02-29 06:59, Steven Dake (stdake) wrote:
>> Hey folks,
>> 
>> It should be obvious that commiters should be testing their changes, but
>> unfortunately this is not always the case.  With the recent state of the
>> gate relating to the introduction of Docker 1.10.z breaking the gate
>>  for 1 week followed by a keystone change upstream breaking the gate for
>> one week, I'd like to make certain the gate stays green.
>> 
>> Jeffrey Zhang resolved the gate with [1].  I'd ask that everyone that
>> has a patch in the queue rebase on master and resubmit their changes.
>
>This is not needed, the CI system always rebases if you run tests. To
>get current tests, a simple "recheck" is enough.
>
>Also, we test in the gate before merging - again after rebasing to head.
>That should take care of not merging anything broken. Running recheck
>after a larger change will ensure that you have recent results.

Andreas,

Thanks for the recheck information.  I thought the gate ran against what
it was submitted with as head.  We don't have any gate jobs at present (or
many) they are mostly check jobs, so its pre-merge checking that we need
folks to do.

Regards,
-stev

>
>>  The result of that should be a green gate.  If you already have votes
>> on your patches and they are rebased, I believe gerrit will leave the
>> vote intact.  If not, the core reviewers who reviewed your patch
>> originally will be happy to ack a simple rebase on master.
>> 
>> For core reviewers:
>> Please do not approve patches that do not pass the gate.  If the gate is
>> broken, our priority should be on fixing the gate.  Please wait for
>> workflows until the gate is green or a recheck has produced a green
>> gate.  I realize our gate isn't perfect, but if its half-red it doesn't
>> give developers a good sense of confidence their patch is correct (or
>> not correct).  What ends up happening in that scenario is core reviewers
>> end up having to pull down every change to personally test it.  We have
>> a lot of work queued up, and the gate should provide some level of
>> confidence that the change doesn't break things, especially with the
>> recent addition of the dead-chicken testing nova boot operation.
>> 
>> When it comes to multinode, we will have to do manual testing, but I'd
>> prefer to sort out any breakages during the RCs since manual testing
>> won't necessarily test the same merge order as the core reviewers are
>> using to manually test multinode.
>
>Andreas
>
>> Thanks in advance!
>> -steve
>> 
>> [1] https://review.openstack.org/#/c/285625
>> 
>> 
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>
>
>-- 
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>   HRB 21284 (AG Nürnberg)
>GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [magnum] Discussion of supporting single/multiple OS distro

[Cammann, Tom]

One of the main reasons for moving to a "bay driver” model was to allow us to
focus our efforts. We talked about focusing our support to the distros with a
religion around them, e.g. Ubuntu and a Red Hat derivative.

Being frank, I do not see much benefit in supporting a small distro if we have
support for a big one. We have seen the templates for these various distros
languish in the past and become quickly outdated. I would much rather have a
concerted effort around a single distro.

The way we could support multiple distros in Magnum would be to create a new
“bay driver” for that distro+template+template_definition. This set of items
would be self contained and would not interact with another bay driver that
used that same COE. This will allow that bay driver to move at the pace of the
team working on it and explicitly list out the features supported by this bay
driver. As it currently stands it is difficult to understand the parity between
two distros using the same COE.

I raised the concern that this could lead to a duplication of code, but we felt
that this refactor had more benefits and we could easily work around this
duplication.

Tom


From: Hongbin Lu >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, 29 February 2016 at 16:40
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [magnum] Discussion of supporting single/multiple OS 
distro

Hi team,

This is a continued discussion from a review [1]. Corey O'Brien suggested to 
have Magnum support a single OS distro (Atomic). I disagreed. I think we should 
bring the discussion to here to get broader set of inputs.

Corey O'Brien
From the midcycle, we decided we weren't going to continue to support 2 
different versions of the k8s template. Instead, we were going to maintain the 
Fedora Atomic version of k8s and remove the coreos templates from the tree. I 
don't think we should continue to develop features for coreos k8s if that is 
true.
In addition, I don't think we should break the coreos template by adding the 
trust token as a heat parameter.

Hongbin Lu
I was on the midcycle and I don't remember any decision to remove CoreOS 
support. Why you want to remove CoreOS templates from the tree. Please note 
that this is a very big decision and please discuss it with the team 
thoughtfully and make sure everyone agree.

Corey O'Brien
Removing the coreos templates was a part of the COE drivers decision. Since 
each COE driver will only support 1 distro+version+coe we discussed which ones 
to support in tree. The decision was that instead of trying to support every 
distro and every version for every coe, the magnum tree would only have support 
for 1 version of 1 distro for each of the 3 COEs (swarm/docker/mesos). Since we 
already are going to support Atomic for swarm, removing coreos and keeping 
Atomic for kubernetes was the favored choice.

Hongbin Lu
Strongly disagree. It is a huge risk to support a single distro. The selected 
distro could die in the future. Who knows. Why make Magnum take this huge risk? 
Again, the decision of supporting single distro is a very big decision. Please 
bring it up to the team and have it discuss thoughtfully before making any 
decision. Also, Magnum doesn't have to support every distro and every version 
for every coe, but should support *more than one* popular distro for some COEs 
(especially for the popular COEs).

Corey O'Brien
The discussion at the midcycle started from the idea of adding support for RHEL 
and CentOS. We all discussed and decided that we wouldn't try to support 
everything in tree. Magnum would provide support in-tree for 1 per COE and the 
COE driver interface would allow others to add support for their preferred 
distro out of tree.

Hongbin Lu
I agreed the part that "we wouldn't try to support everything in tree". That 
doesn't imply the decision to support single distro. Again, support single 
distro is a huge risk. Why make Magnum take this huge risk?

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

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

[openstack-dev] [nova] nova hooks - document & test or deprecate?

[Sean Dague]

The nova/hooks.py infrastructure has been with us since early Nova. It's
currently only annotated on a few locations - 'build_instance',
'create_instance', 'delete_instance', and 'instance_network_info'. It's
got a couple of unit tests on it, but nothing that actually tests real
behavior of the hooks we have specified.

It does get used in the wild, and we do break it with changes we didn't
ever anticipate would impact it -
https://bugs.launchpad.net/nova/+bug/1518321

However, when you look into how that is used, it's really really odd and
fragile -
https://github.com/richm/rdo-vm-factory/blob/master/rdo-ipa-nova/novahooks.py#L248


def pre(self, *args, **kwargs):
# args[7] is the injected_files parameter array
# the value is ('filename', 'base64 encoded contents')
ipaotp = str(uuid.uuid4())
ipainject = ('/tmp/ipaotp', base64.b64encode(ipaotp))
args[7].extend(self.inject_files)
args[7].append(ipainject)

In our continued quest on being more explicit about plug points it feels
like we should other document the interface (which means creating
stability on the hook parameters) or we should deprecate this construct
as part of a bygone era.

I lean on deprecation because it feels like a thing we don't really want
to support going forward, but I can go either way.

-Sean

P.S. I'm starting to look at in tree functional testing for all of this,
in the event that we decide not to deprecate it. It's definitely made a
little hard by the way all exceptions are caught when hooks go wrong.

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [neutron]Ports not binding correctly after restart

[Sergio Morales Acuña]

Hi all.
I'm facing a problem with "Neutron/OVS/DVR" in "Liberty".

With 3 network/compute nodes I created, successfully, 100 tenants, 100
networks (1 per tenants), 3 DHCP agents per network and 100 routers (1 per
network), 100 VM (1 per tenant) and 1 FIP per VM. All working and
responding.

The problem occurs after restarting the servers. Now i have some routers
without communications, dhcp agents not connected to the tenant network and
VM running but not connected to the router/fip. This happen randomly for
any router/dhcp agent/ or VM.

There's a way to force a port binding check in neutron? How i can make the
restart process more effective?

I'm using Neutron 7.0.1 (DVR), RHEL 7.2, Kolla with RDO Liberty and  OVS
2.3.2.

I tried neutron 7.0.4 (from stable/libery) with OVS 2.3.2 and OVS 2.4.0.

I would appreciate any comments, suggestions or patches under review.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev