Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state

[Ramakrishnan G]

My opinion:

- If a new API is desirable by operators who would like to skip a few steps
in Ironic before making it active, then we should do it.   I mean we should
allow them to skip the enroll state and manageable state, thereby giving
them an opportunity to land the node in "manageable" or "available" state
by default.

- Default state (by default) should be "enroll" as that's where the state
of a node in Ironic begins. May be optionally it can be tweaked in
ironic.conf.

- I don't like the idea to land a node directly in active state.  The main
reason being it differs from driver to driver, what it takes to bring a
node to active and what is required for a take over for the active node.
For example, while deploying a partition image (by pxe or virtual media
drivers), the uuid of the root partition should be available in the
driver_internal_info for take_over to happen.  So, it would mean that even
for existing drivers, we would need to at least provide a mechanism for
writing driver_internal_info from the API which is not desirable.  It is
very much a valid use case to do import.  From first thought, I think we
should have a new API endpoint to request such an import and a new method
in DeployInterface (not an abstract method) for importing bare metals from
another system.  The API should allow parameters to be passed from the
driver to do the import, optionally requesting to reboot the bare metal
after it is imported (to make sure that Ironic can properly manage the node
again).  The new method in DeployInterface should do what it takes to
import the bare metal given the parameters.  But, that might be a different
story :).

Regards,
Ramesh

On Wed, Aug 19, 2015 at 5:35 AM, Ruby Loo  wrote:

>
>
>
>>> On 17 August 2015 at 20:20, Robert Collins 
>>> wrote:
>>>
 On 11 August 2015 at 06:13, Ruby Loo  wrote:
 > Hi, sorry for the delay. I vote no. I understand the rationale of
 trying to
 > do things so that we don't break our users but that's what the
 versioning is
 > meant for and more importantly -- I think adding the ENROLL state is
 fairly
 > important wrt the lifecycle of a node. I don't particularly want to
 hide
 > that and/or let folks opt out of it in the long term.
 >
 > From a reviewer point-of-view, my concern is me trying to remember
 all the
 > possible permutations/states etc that are possible to make sure that
 new
 > code doesn't break existing behavior. I haven't thought out whether
 adding
 > this new API would make that worse or not, but then, I don't really
 want to
 > have to think about it. So KISS as much as we can! :)

 I'm a little surprised by this, to be honest.

 Here's why: allowing the initial state to be chosen from
 ENROLL/AVAILABLE from the latest version of the API is precisely as
 complex as allowing two versions of the API {old, new} where old
 creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
 difference I can see is that eventually someday if {old} stops being
 supported, then and only then we can go through the code and clean
 things up.

 It seems to me that the costs to us of supporting graceful transitions
 for users here are:

 1) A new version NEWVER of the API that supports node state being one
 of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
 AVAILABLE when not supplied.
 2) Supporting the initial state of AVAILABLE indefinitely rather than
 just until we *delete* version 1.10.
 3) CD deployments that had rolled forward to 1.11 will need to add the
 state parameter to their scripts to move forward to NEWVER.
 4) Don't default the client to the veresions between 1.10 and NEWVER
 versions at any point.

 That seems like a very small price to pay on our side, and the
 benefits for users are that they can opt into the new functionality
 when they are ready.

 -Rob
>>>
>>>
> After thinking about this some more, I'm not actually going to address
> Rob's points above. What I want to do is go back and discuss... what do
> people think about having an API that allows the initial provision state to
> be specified, for a node that is created in Ironic. I'm assuming that
> enroll state exists :)
>
> Earlier today on IRC, Devananda mentioned that "there's a very strong case
> for allowing a node to be created in any of the stable states (enroll,
> manageable, available, active)". Maybe he'll elaborate later on this. I
> know that there's a use case where there is a desire to import nodes (with
> instances on them) from another system into ironic, and have them be active
> right away. (They don't want the nodes to go from
> enroll->verifying->manageable->cleaning!!!->available!!!->active).
>
> 1. What would the default provision state be, if it wasn't specified?
> A. 'available' to be backwards compatible with pre-v1.11
> or
> B. 'enroll' to b

Re: [openstack-dev] [Neutron] neutron-lbaas code structure problem

[Gareth]

Thanks Brandon, got it.

It is easy to understand :)

On Sat, Aug 15, 2015 at 2:07 AM, Brandon Logan 
wrote:

> ​Hi Gareth,
>
> The reason for this is because lbaas v1 is in the
> services/loadbalancer/drivers path.  This path was maintained from when
> neutron-lbaas was just another directory in the neutron repo.  Once we
> moved to neutron-lbaas as its own repo and going forward with lbaas v2, the
> decision was made to not maintain that same path for v2.  There's no reason
> to keep that path for v2 as v1 will be deprecated and eventually removed
> and we did not want to be stuck with that path.  Eventually the plugin.py
> module will have to be moved to the root directory as well from
> services/loadbalancer but thats a minor change.
>
>
> Thanks,
>
> Brandon
> --
> *From:* Gareth 
> *Sent:* Thursday, August 13, 2015 9:38 PM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Neutron] neutron-lbaas code structure problem
>
> Dear neutron guys.
>
> [0]
> https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/drivers
> [1]
> https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/services/loadbalancer/drivers
>
> the codes under these two paths are 'same' (implement same things with v1
> and v2), but why use two different code paths here?
>
> --
> Gareth
>
> *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*
> *OpenStack contributor, kun_huang@freenode*
> *My promise: if you find any spelling or grammar mistakes in my email from
> Mar 1 2013, notify me *
> *and I'll donate $1 or ￥1 to an open organization you specify.*
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Gareth

*Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*
*OpenStack contributor, kun_huang@freenode*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
__
OpenStack Development Mailing 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] API: Question on 'Retry-After': 0 in HTTPForbidden

[Alex Xu]

+1 for Retry-After is wrong for quota case

> 在 2015年8月19日，下午1:32，GHANSHYAM MANN  写道：
> 
> Retry-After

__
OpenStack Development Mailing 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] Vendor tools related to Ironic

[Ramakrishnan G]

Hi All,

This is an informational mail for both vendor tool developers and Ironic
community.

For vendor tool developers - We decided the last week's Ironic meeting [1]
that vendors who want to share tools/scripts related to Ironic, can do so
in their own preferred way (personal github repositories or
stackforge/openstack github repositories ((provided it gets accepted))).
Such vendor tools can be listed in Ironic wiki[3].  These vendor tools will
not be reviewed/maintained by the Ironic community.

For Ironic community - After having taken the action item for wikifying
them, I have just written down wiki pages ([2] and [3]), and linked them to
the main page of our wiki[4].  This just captures what we discussed in the
meeting, plus a bit of additions from my side.  Please feel free to discuss
and edit them as required.

[1]
http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-08-17-17.00.log.txt
[2] https://wiki.openstack.org/wiki/Ironic/ThirdPartyVendorToolsDeveloperDoc
[3] https://wiki.openstack.org/wiki/Ironic/ThirdPartyVendorToolsList
[4] https://wiki.openstack.org/wiki/Ironic

Thanks.

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

Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.

[Xie, Xianshan]

Hi Abhi,
   IIUC, you should create and configure slaves(these slaves can be VMs or real 
physical machine) in Jenkins.
And the nodepool is used to create and pool VMs automatically, and these VMs 
should be run on the slaves.
Then, while CI wants to build and execute a testcase, especially which attempts 
to be run on an isolated host, the nodepool will match a proper VM for this 
testcase.

Hope this might help you.


Xiexs


From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
Sent: Tuesday, August 18, 2015 1:46 PM
To: openstack-in...@lists.openstack.org; OpenStack Development Mailing List 
(not for usage questions)
Subject: Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using 
Nodepool for creating slaves.

Also adding the following:

  *   
https://github.com/openstack-infra/project-config/tree/master/nodepool/elements
Does this means that we don't have to take care of creating slaves(i.e; 
installing slave using scripts as we have done in master) and it will be done 
automatically, and also we don't have to configure slaves in Jenkins.

A bit confusing for me so if anyone can explain it to me then it will be very 
helpful.

On Tue, Aug 18, 2015 at 11:11 AM, Abhishek Shrivastava 
mailto:abhis...@cloudbyte.com>> wrote:
Hi Folks,

I was going through Ramy's guide for setting up CI, there I found out the 
following:

  *   
https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves
But I don't get the fact on how to create the image, also what major settings 
need to be done to make the config perfect for use. Can anyone help me with 
that?

--
[https://docs.google.com/uc?export=download&id=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0&revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ]
Thanks & Regards,
Abhishek
Cloudbyte Inc.



--
[https://docs.google.com/uc?export=download&id=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0&revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ]
Thanks & Regards,
Abhishek
Cloudbyte 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] [QA][tempest] schema extensions

[Tikkanen, Viktor (Nokia - FI/Espoo)]

Thank you for the references!

> -Original Message-
> From: ext Ken'ichi Ohmichi [mailto:ken1ohmi...@gmail.com]
> Sent: Wednesday, August 19, 2015 2:48 AM
...
> Is it difficult to make these properties upstream?
> Vendor specific properties will make API different between clouds, and
> that will make the interoperability difficult.
> There was a defcore(interoperability) discussion also related to this:
> http://lists.openstack.org/pipermail/defcore-committee/2015-
> June/000849.html

I'm afraid that not all the currently used additional properties can
be upstreamed as such (some of them contain e.g. references to vendor's
own SW products) but we will probably discuss this possibility with the
vendor in the future.

> As the above mails, current schemas are blocking additional properties for
> * (community devs) accidental additional properties without a new
> microversion
> * (interoperability) vendor-specific properties
> 
> Technically, it is possible to relax this additional properties
> validation on Tempest side because we have implemented similar feature
> on Nova side[1].
> But before that, I'd like to know whether that is a right direction or not.
> 
> Thanks
> Ken Ohmichi
> ---
> [1]: https://review.openstack.org/#/c/193858/

IMO it is not a right direction to permanently relax additional properties
validation (for the reasons mentioned above). Actually currently I have to
update only the value of additionalProperties in few places. Of course,
a common parameter like allow_additional_api_properties (or so) would ease
the patching but let's see if somebody else is interested in it...

-Viktor


__
OpenStack Development Mailing 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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Aaron Rosen]

+1 to both!  (Sorry missed this email the first go around).

On Fri, Aug 14, 2015 at 10:25 AM, Mark McClain  wrote:

> +1 to Brandon and Russell.
>
> mark
>
> On Aug 13, 2015, at 2:47 PM, Kevin Benton  wrote:
>
> +1
>
> On Wed, Aug 12, 2015 at 10:43 PM, Akihiro Motoki 
> wrote:
>
>> +1 for both.
>>
>> 2015-08-12 22:45 GMT+09:00 Kyle Mestery :
>>
>>> It gives me great pleasure to propose Russell Bryant and Brandon Logan
>>> as core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon
>>> have both been incredible contributors to Neutron for a while now. Their
>>> expertise has been particularly helpful in the area they are being proposed
>>> in. Their review stats [1] place them both comfortably in the range of
>>> existing Neutron core reviewers. I expect them to continue working with all
>>> community members to drive Neutron forward for the rest of Liberty and into
>>> Mitaka.
>>>
>>> Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
>>> please vote +1/-1 for the addition of Russell and Brandon.
>>>
>>> Thanks!
>>> Kyle
>>>
>>> [1] http://stackalytics.com/report/contribution/neutron-group/90
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
>>
>
>
> --
> Kevin Benton
> __
> OpenStack Development Mailing 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] API: Question on 'Retry-After': 0 in HTTPForbidden

[GHANSHYAM MANN]

That is nice point. IMO also Retry-After does not looks good for Quota
error (in all three mentioned case) and actually we are trying to tell
user in case of Quota error, retry this request after 0 sec.

Thanks
Ghanshyam

On Wed, Aug 19, 2015 at 12:34 AM, Chen CH Ji  wrote:
> When doing patch[1] Ken'ichi raise a good suggestion on not raise
> Retry-After according to [2]
>
> seems nova also when doing create[3] and resize[4] a server nova may raise
> those, too
> is this a bug or something made on purpose? Thanks
>
> [1]https://review.openstack.org/#/c/180469/5/nova/api/openstack/compute/tenant_networks.py
> [2]http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> [3]https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L591
> [4]https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L846
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
> Phone: +86-10-82454158
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann

__
OpenStack Development Mailing 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] Possible issues cryptography 1.0 and os-client-config 1.6.2

[John Griffith]

On Tue, Aug 18, 2015 at 7:42 PM, John Griffith 
wrote:

>
>
> On Tue, Aug 18, 2015 at 2:14 PM, Robert Collins  > wrote:
>
>> On 19 August 2015 at 03:51, Sean Dague  wrote:
>>
>> > So... I'm at Linux Con this week, meaning that things will be slow. I
>> > think - https://review.openstack.org/#/c/208582/ (slightly updated this
>> > morning) will get devstack users working again. And I agree, we really
>> > need devstack and the gate to be convergent on their solution here, not
>> > divergent.
>>
>> So unless something has changed, devstack users are broken only on
>> Fedora - and the constraints thing won't protect them at this stage
>> because of two things.
>>
>> Firstly, the bug isn't a cryptography bug - its a setuptools / pip
>> thing resulting in the .so pip installs being in the arch neutral path
>> rather than lib64, and this would work except that devstack also
>> installs python-cffi, which then masks the pip updated one. I don't
>> know why devstack is installing the binary package :/. This is a
>> Fedora platform specific bug - it doesn't show up on Ubuntu - either
>> because devstack doesn't install the ubuntu python-cffi package, or
>> because pip/setuptools on ubuntu don't have the same disconnect with
>> system packages in the same way. I'm not sure which.
>>
>> Secondly, until we have a gate on openstack/requirements that checks
>> devstack-on-fedora, fedora developers will be exposed to this sort of
>> thing from time to time :/.
>>
>> -Rob
>>
>> --
>> Robert Collins 
>> Distinguished Technologist
>> HP Converged Cloud
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> ​Catching up on this thread, looks like the referenced devstk change above
> (987dc6453e8e3a8a46d748059378564c42bafc5c) merged and broke things.  Seems
> we don't install opt/stack/requirements so stack.sh is failing for third
> party CI's that don't use node-pool (suspect they'll fail when they're
> nodes are rebuilt similar to last weeks issue with keystone).
>
> Went ahead and confirmed that a fresh download and stack.sh locally fails,
> going to have a look after dinner but thought maybe somebody already knows
> what's up with this.
>
> Thanks,
> John
>
> ​For those that are interested, Clark pointed me to this patch [1] which
in fact the addresses the issue I was running in to.

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

Thanks,
John
​
__
OpenStack Development Mailing 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] [CI] How to run dsvm_tempest_full without nodepool ?

[Tang Chen]

Hi Asselin, Abhishek,
CC: all,

After a long time, I think I failed to setup a nodepool.

I can start nodepool daemon, but when launching nodes with a ready state 
image.




ERROR nodepool.NodeLauncher: Exception launching node id: 7 in provider: 
local_01 error:


Traceback (most recent call last):

  File "/usr/local/lib/python2.7/dist-packages/nodepool/nodepool.py", 
line 409, in _run


dt = self.launchNode(session)

  File "/usr/local/lib/python2.7/dist-packages/nodepool/nodepool.py", 
line 472, in launchNode


server = self.manager.waitForServer(server_id, self.launch_timeout)

  File 
"/usr/local/lib/python2.7/dist-packages/nodepool/provider_manager.py", 
line 458, in waitForServer


return self._waitForResource('server', server_id, timeout)

  File 
"/usr/local/lib/python2.7/dist-packages/nodepool/provider_manager.py", 
line 429, in _waitForResource


self.provider.name)):

  File "/usr/local/lib/python2.7/dist-packages/nodepool/nodeutils.py", 
line 42, in iterate_timeout


raise Exception("Timeout waiting for %s" % purpose)

Exception: Timeout waiting for server 
d7150309-0a33-4338-b4e8-268c719f785b in local_01



Have you ever seen this error before ?


Seeing from the log, I think dsvm-tempest-full test needs nodepool support.

Is dsvm-tempest-full test able to be executed without nodepool ?


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] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

[John Griffith]

On Tue, Aug 18, 2015 at 2:14 PM, Robert Collins 
wrote:

> On 19 August 2015 at 03:51, Sean Dague  wrote:
>
> > So... I'm at Linux Con this week, meaning that things will be slow. I
> > think - https://review.openstack.org/#/c/208582/ (slightly updated this
> > morning) will get devstack users working again. And I agree, we really
> > need devstack and the gate to be convergent on their solution here, not
> > divergent.
>
> So unless something has changed, devstack users are broken only on
> Fedora - and the constraints thing won't protect them at this stage
> because of two things.
>
> Firstly, the bug isn't a cryptography bug - its a setuptools / pip
> thing resulting in the .so pip installs being in the arch neutral path
> rather than lib64, and this would work except that devstack also
> installs python-cffi, which then masks the pip updated one. I don't
> know why devstack is installing the binary package :/. This is a
> Fedora platform specific bug - it doesn't show up on Ubuntu - either
> because devstack doesn't install the ubuntu python-cffi package, or
> because pip/setuptools on ubuntu don't have the same disconnect with
> system packages in the same way. I'm not sure which.
>
> Secondly, until we have a gate on openstack/requirements that checks
> devstack-on-fedora, fedora developers will be exposed to this sort of
> thing from time to time :/.
>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
​Catching up on this thread, looks like the referenced devstk change above
(987dc6453e8e3a8a46d748059378564c42bafc5c) merged and broke things.  Seems
we don't install opt/stack/requirements so stack.sh is failing for third
party CI's that don't use node-pool (suspect they'll fail when they're
nodes are rebuilt similar to last weeks issue with keystone).

Went ahead and confirmed that a fresh download and stack.sh locally fails,
going to have a look after dinner but thought maybe somebody already knows
what's up with this.

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

Re: [openstack-dev] [ironic] Re: New API for node create, specifying initial provision state

[Ruby Loo]

>> On 17 August 2015 at 20:20, Robert Collins 
>> wrote:
>>
>>> On 11 August 2015 at 06:13, Ruby Loo  wrote:
>>> > Hi, sorry for the delay. I vote no. I understand the rationale of
>>> trying to
>>> > do things so that we don't break our users but that's what the
>>> versioning is
>>> > meant for and more importantly -- I think adding the ENROLL state is
>>> fairly
>>> > important wrt the lifecycle of a node. I don't particularly want to
>>> hide
>>> > that and/or let folks opt out of it in the long term.
>>> >
>>> > From a reviewer point-of-view, my concern is me trying to remember all
>>> the
>>> > possible permutations/states etc that are possible to make sure that
>>> new
>>> > code doesn't break existing behavior. I haven't thought out whether
>>> adding
>>> > this new API would make that worse or not, but then, I don't really
>>> want to
>>> > have to think about it. So KISS as much as we can! :)
>>>
>>> I'm a little surprised by this, to be honest.
>>>
>>> Here's why: allowing the initial state to be chosen from
>>> ENROLL/AVAILABLE from the latest version of the API is precisely as
>>> complex as allowing two versions of the API {old, new} where old
>>> creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
>>> difference I can see is that eventually someday if {old} stops being
>>> supported, then and only then we can go through the code and clean
>>> things up.
>>>
>>> It seems to me that the costs to us of supporting graceful transitions
>>> for users here are:
>>>
>>> 1) A new version NEWVER of the API that supports node state being one
>>> of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
>>> AVAILABLE when not supplied.
>>> 2) Supporting the initial state of AVAILABLE indefinitely rather than
>>> just until we *delete* version 1.10.
>>> 3) CD deployments that had rolled forward to 1.11 will need to add the
>>> state parameter to their scripts to move forward to NEWVER.
>>> 4) Don't default the client to the veresions between 1.10 and NEWVER
>>> versions at any point.
>>>
>>> That seems like a very small price to pay on our side, and the
>>> benefits for users are that they can opt into the new functionality
>>> when they are ready.
>>>
>>> -Rob
>>
>>
After thinking about this some more, I'm not actually going to address
Rob's points above. What I want to do is go back and discuss... what do
people think about having an API that allows the initial provision state to
be specified, for a node that is created in Ironic. I'm assuming that
enroll state exists :)

Earlier today on IRC, Devananda mentioned that "there's a very strong case
for allowing a node to be created in any of the stable states (enroll,
manageable, available, active)". Maybe he'll elaborate later on this. I
know that there's a use case where there is a desire to import nodes (with
instances on them) from another system into ironic, and have them be active
right away. (They don't want the nodes to go from
enroll->verifying->manageable->cleaning!!!->available!!!->active).

1. What would the default provision state be, if it wasn't specified?
A. 'available' to be backwards compatible with pre-v1.11
or
B. 'enroll' to be consistent with v1.11+
or
?


2. What would it mean to set the initial provision state to something other
than 'enroll'?

manageable

In our state machinery[0], a node goes from enroll -> verifying ->
manageable. For manageble to be initial state, does it mean that
A. whatever is needed for enroll and verifying is done and succeeds (under
the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying)
or
C. no enroll or verifying is done, it goes straight to manageble

I'm fine with A.I'm not sure that B makes sense and I definitely don't
think C makes sense. To date, verifying means checking that the conductor
can get the power state on the node, to verify the supplied power
credentials. I don't think it is a big deal if we skip this step; it just
means that the next time some action is taken on the node, it might fail.

available

In our state machinery, a node goes from enroll -> verifying -> manageable
-> cleaning -> available. For available to be initial state, does it mean
that
A. whatever is needed for enroll, verifying, cleaning is done and succeeds
(under the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying or
cleaning)
or
??

active

In our state machinery, a node goes from enroll -> verifying -> manageable
-> cleaning -> available->deploying->active. For active to be initial
state, does it mean that
A. whatever is needed for enroll, verifying, cleaning, deploying is done
and succeeds (under the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying or
cleaning)
or
C. whatever is needed for enroll and I dunno, any 'takeover' stuff by
conductor or whatever node states need to be updated to be in active?

--ruby

[0] http://docs.openstack.org/developer/ironic/dev/st

Re: [openstack-dev] [cinder] Midcycle Sprint Summary

[Jay S. Bryant]

Great summary.  We covered a lot of ground.

Thanks Mike!

On 08/17/2015 10:53 AM, Mike Perez wrote:

A *summary* of the Cinder midcycle sprint, in attempt to keep your attention.
Full meeting notes available [1].

Image Caching
=
Glance Cinder backend store + Cinder Image Caching are so similar, it would
just be confusing to operators. We'll document only about the Cinder Image
Caching since the Glance backend store is limited in comparison.


Revisit Spec Review
===
The PTL in the future will be the only one to +2/A specs after sufficient +1's
have been given, and notice of approval to follow in the Cinder meeting.


When Specs and Blueprints are needed

Done https://wiki.openstack.org/wiki/Cinder/how-to-contribute-new-feature


People can guess UUID's that don't belong to them
=
Who cares. In past security discussions this has been a moot point.


Update Hypervisor about extending attached volumes
==
Add support to os-brick, but the Nova team has to be fine with this only
supporting Libvirt for now.


Microversions
=
We're doing it.


Getting rid of API extensions
=
Move obvious things over (volume attach, type manager) to core API controllers.
Deprecate existing extensions and have these use core API controller code. Get
rid of the silly os- prefix in endpoints. Use Microversions to know when the
API has the new extensions in core controllers.


Third Party CI for target drivers and zone manager drivers
==
Yes. This is already happening for Brocade and Cisco in Liberty!


Cinder <-> Nova API communication
=
Agreed on how the Cinder API should be used. It requires changes and
a Microversion bump on the Nova side. Design summit session to follow.


Out of tree drivers
===
No.


Exposing force-detach of a volumes
==
Yes, this will be in nova-manage in Liberty.


HA and Cinder
=
We need cross project consensus first. There are existing issues that can be
fixed without a DLM. Fix those first. Mike Perez will be leading cross project 
discussion at the summit.


Replication V2
==
John Griffith did extreme programming with the group and posted a review.
A limited replication feature with async and manual failover should be in
Liberty.


ABC classes for each driver feature
===
Keeping the current solution [2].


[1] - https://etherpad.openstack.org/p/cinder-meetup-summer-2015
[2] - http://lists.openstack.org/pipermail/openstack-dev/2015-June/067563.html




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

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor for core

[Jay S. Bryant]

+1

He has been doing good reviews and shown a sustained commitment.

Well done!

Jay

On 08/13/2015 02:13 PM, Mike Perez wrote:

It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

Gorka's contributions to Cinder core have been much apprecated:

https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

60/90 day review stats:

http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

Cinder core, please reply with a +1 for approval. This will be left
open until August 19th. Assuming there are no objections, this will go
forward after voting is closed.




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

Re: [openstack-dev] [QA][tempest] schema extensions

[Ken'ichi Ohmichi]

Hi Viktor,

2015-08-17 23:26 GMT-07:00 Tikkanen, Viktor (Nokia - FI/Espoo)
:
>
> I have I question regarding validating responses during API tests.
>
> Has it been decided some time ago that no additional properties
> are allowed when verifying response schemas during API tests?

There was the related mail:

http://lists.openstack.org/pipermail/openstack-dev/2015-February/057613.html

> I have an OpenStack based product that contains few additional
> properties in it's compute API and few tempest cases fail like:
>
> tempest_lib.exceptions.InvalidHTTPResponseBody: HTTP response body is invalid 
> json or xml
> Details: HTTP response body is invalid (Additional properties are not allowed 
> (u'nics' was unexpected)
>
> So currently I have to update related schema descriptions located
> under tempest/api_schema/ in order to get those tests passed.
>
> Just wondering if there is some more convenient way to handle such
> kind of drawbacks. Could this schema validating be more flexible
> (e.g. with posibility to define additional properties in some single
> place like tempest.conf file)?

Is it difficult to make these properties upstream?
Vendor specific properties will make API different between clouds, and
that will make the interoperability difficult.
There was a defcore(interoperability) discussion also related to this:
http://lists.openstack.org/pipermail/defcore-committee/2015-June/000849.html

As the above mails, current schemas are blocking additional properties for
* (community devs) accidental additional properties without a new microversion
* (interoperability) vendor-specific properties

Technically, it is possible to relax this additional properties
validation on Tempest side because we have implemented similar feature
on Nova side[1].
But before that, I'd like to know whether that is a right direction or not.

Thanks
Ken Ohmichi
---
[1]: https://review.openstack.org/#/c/193858/

__
OpenStack Development Mailing 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] [stable] [infra] How to auto-generate stable release notes

[Robert Collins]

On 18 August 2015 at 01:46, Thierry Carrez  wrote:

Following on from the IRC discussion about release notes.

< ttx> * we want consumers of the stable branch (from random commit
and from tagged versions) to get a valid release notes document
< ttx> * Some things in that document (like OSSA numbers) we only know
after the commit is pushed so we need a way to retroactively fix those

So 'random commit' here is a point in time - I think its reasonable to
assert that if a commit isn't tagged, its release notes are not final.

So before I dive into detail, here's the basic design I think we can use.

1) release notes are derived from the tree/git history. We might
eventually use both, for instance.
2) commits are needed to change release notes.
3) Notes are mutable in that a clone today vs a clone tomorrow might
have different release notes about the same change.
4) Notes are immutable in that for a given git hash/tag the release
notes will be the same. Tagging a commit will change the version
description but that is all.

Design assumptions:
- We want to avoid merge hell when sheparding in a lot of
release-note-worthy changes, which we expect to happen on stable
branches always, and at release times on master branches.
- We want writing a release note to be straight forward
- We do not want release notes to be custom ordered within a release.
As long as the ordering is consistent it is ok.
- We must be able to entirely remove a release note.
- We must not make things progressively slow down to a crawl over
years of usage.

Proposed data structure:
- create a top level directory in each repo called release-notes
- within that create a subdirectory called changes.
- within the release-notes dir we place yaml files containing the
release note inputs.
- within the 'changes' subdirectory, the name of the yaml file will be
the gerrit change id in a canonical form.
   E.g. I1234abcd.yaml
   This serves two purposes: it guarantees file name uniqueness (no
merge conflicts) and lets us
   determine which release to group it in (the most recent one, in
case of merge+revert+merge patterns).
- we also create files that roll up all the notes within history
versions - named by the version. e.g. release-notes/1.2.3.yaml.

Yaml schema:
prelude: prelude prose
notes:
 - note1
 - note2
 - note3

Processing:
1) determine the revisions we need to generate release notes for. By
default generate notes for the current minor release. (E.g. if the
tree version is 1.2.3.dev4 we would generate release notes for 1.2.0,
1.2.1, 1.2.2, 1.2.3[which dev4 is leading up to]).
2) For each version: scan all the commits to determine gerrit change-id's.
 i) read in all those change ids .yaml files and pull out any notes within them.
 ii) read in any full version yaml file (and merge in its contained notes)
 iii) Construct a markdown document as follows:
  a) Sort any preludes (there should be only one at most, but lets not
error if there are multiple)
  b) sort any notes
  c) for each note transform it into a bullet point by prepending its
first line with '- ' and every subsequent line with '  ' (two spaces
to form a hanging indent).
  d) strip any trailing \n's from everything.
  e) join the result - '\n'.join(chain(preludes, notes))
 iv) we output the resulting file to release-notes/$version.md where
$version is the pbr reported version for the tree (e.g. in the example
above it would be 1.2.3.dev4, *not* 1.2.3).
3) possibly symlink the highest output version to ./RELEASENOTES.md or
something, so other tooling can look for a constant value.

If we want to put release notes in sdists, we can have pbr do this,
otherwise it could just be built entirely separately.

I recommend we start with it entirely separate: part of the
release-management tooling.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [openstack-deb] Devstack stable/juno fails to install

[Tony Breeds]

On Tue, Aug 18, 2015 at 10:04:56PM +, Jeremy Stanley wrote:
> On 2015-08-18 15:48:08 -0500 (-0500), Matt Riedemann wrote:
> [...]
> > You'd also have to raise the cap on swiftclient in g-r stable/juno
> > to python-swiftclient>=2.2.0,<2.4.0.
> [...]
> 
> Followed by stable point releases of everything with a stable/juno
> branch and a {test-,}requirements.txt entry for python-swiftclient.
> Oh, and some of those things might _also_ have overly-strict caps in
> global-requirements.txt, so iterate until clean.

Oh boy ;P
 
Yours Tony.


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

Re: [openstack-dev] [neutron] New networking-calico project

[Neil Jerram]

Although the DHCP-related patches below are I think very close to mergeable, 
Brian Haley on IRC queried what, process-wise, motivates merging them now (for 
Liberty).

I think he's right that something is missing, so I'd like to discuss filling 
that hole here. What has happened so far is this:

- https://review.openstack.org/#/c/198439/ described 'routed networking', which 
is the ultimate motivation for these patches. 

- I realised/was told that there should be an RFE bug, per current process, so 
raised https://bugs.launchpad.net/neutron/+bug/1472704

- Those contributed to the beginning of discussions about supporting 'routed' 
or 'L3' networks in Neutron - which are ongoing and will take Mitaka at least 
to refine. 

- Nevertheless, the DHCP-related patches are still valuable now (as explained 
below) and feasible within the Liberty timescale, so I've continued refining 
those.

- Discussions, which I believe supported this in principle, took place in 
neutron-drivers [1][2] and main Neutron [3] IRC meetings.

[1] 
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-14-15.04.log.html‎

[2]
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-21-15.00.log.html

[3] discussion between 14:49:44 and 14:56:49 at 
http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-28-14.01.log.html

The specific process issue now is that the patches that (IMO) make sense for 
Liberty reference a bug (1472704) that has a much wider scope and so is quite 
correctly not approved for Liberty. 

So, what to do? My guess is to raise a new RFE bug that just motivates the DHCP 
agent support that I'd like to achieve - by way of the existing patches - in 
the Liberty timescale, ask neutron-drivers to approve that, and update the 
patches to reference that bug instead. 

Does that sound right?

Regards, 
      Neil 


‎
  Original Message  
From: Neil Jerram
Sent: Monday, 17 August 2015 18:47
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] New networking-calico project

I'd like to announce networking-calico, a new project within the Neutron
stadium to provide OpenStack integration pieces for Project Calico
[1][2]. In a sentence, Calico is a backend that uses routing and
iptables to provide IP-level connectivity between VMs, instead of - as
most Neutron backends do - using bridging to provide an effective L2
broadcast domain. You can read about why that might be interesting at
[1][2], or in more OpenStack-centric terms at [3].

Calico's semantics are not fully describable by the current Neutron API,
and I plan to contribute to API and data model work to address this. 
Discussion about that has already begun at [3] and in the email thread
about 'routed, segmented networks' [4], and I hope it will continue
through the end of this cycle, in Tokyo, and during Mitaka.

For a practical deployment, though, and with some semantic caveats [5],
Calico-style connectivity can be used already in an OpenStack cluster - 
and we have several operator partners interested in and trialling that. 
My team has been developing and refining this since Icehouse, using
Calico-specific patches to Nova and Neutron, but we are now within
touching distance, we think, of working with vanilla OpenStack when
Liberty is released. We released our v1.0 milestone of the core Calico
code last week [14], our Nova patches were merged in July, and we have
the following core Neutron patches currently in review.

[6] https://review.openstack.org/#/c/205181/
[7] https://review.openstack.org/#/c/206078/
[8] https://review.openstack.org/#/c/206077/
[9] https://review.openstack.org/#/c/206079/

These patches have been through many cycles of review - thanks in
particular to Cedric and Oleg - and are now, I believe, fully tested and
polished. They make small generalizations to the DHCP agent code so
that a networking-calico-provided interface driver will be able to use
it, instead of having to provide a parallel DHCP agent implementation. 
I would particularly appreciate if Neutron core reviewers would consider
reviewing and approving [6] and [7] now, as they are the changes that
would be messiest if I had to reimplement them out-of-tree using some
kind of subclassing approach.

Then the plan for networking-calico is that it will contain docs, an ML2
mechanism driver, a DHCP interface driver, and a Devstack plugin for
Calico. These aren't yet at [10], but I will be getting on with that
shortly, and you can already see those pieces in other forms (which will
be retired) at [11], [12] and [13]. Hence, within the next few weeks, I
hope that networking-calico and the vanilla Neutron tree (+ the core
Calico project) will provide a complete demonstration of this kind of
networking.

Looking ahead, we will also set up a regular IRC meeting for people
interested in networking-ca

Re: [openstack-dev] [openstack-deb] Devstack stable/juno fails to install

[Jeremy Stanley]

On 2015-08-18 15:48:08 -0500 (-0500), Matt Riedemann wrote:
[...]
> You'd also have to raise the cap on swiftclient in g-r stable/juno
> to python-swiftclient>=2.2.0,<2.4.0.
[...]

Followed by stable point releases of everything with a stable/juno
branch and a {test-,}requirements.txt entry for python-swiftclient.
Oh, and some of those things might _also_ have overly-strict caps in
global-requirements.txt, so iterate until clean.
-- 
Jeremy Stanley

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

Re: [openstack-dev] Cross-Project meeting, Tue Aug 18th, 21:00 UTC

[Emilien Macchi]

We did the meeting and you can read the notes here:

http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-08-18-21.01.html

See you next week!

On Tue, Aug 18, 2015 at 8:18 AM, Emilien Macchi  wrote:

> Note for myself: do not take a day off before Cross-project meeting so I
> can send the agenda on time :-)
>
> Dear PTLs, cross-project liaisons and anyone else interested,
>
> We'll have a cross-project meeting today at 21:00 UTC, with the
> following agenda:
>
> * Team announcements (horizontal, vertical, diagonal)
> * How to generate .Z version increments on stable/liberty commits
> * How to autogenerate release notes on stable/liberty commits
> * Return request ID to caller
> * Open discussion
>
> If you're from an horizontal team (Release management, QA, Infra, Docs,
> Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and
> have something to communicate to the other teams, feel free to abuse the
> relevant sections of that meeting and make sure it gets #info-ed by the
> meetbot in the meeting summary.
>
> See you there !
>
> For more details on this meeting, please see:
> https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
> --
> Emilien Macchi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver

[Mathieu Rohon]

hi brandon,

thanks for your answer.

my answers inline,



On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan 
wrote:

> ​So let me make sure I understand this. You want to do a separate service
> plugin for what would normally be separate drivers under one service
> plugin.  The reasons for this are:
>
>
> 1. You dont want users the ability to choose the type, you want it always
> to be the same one
>
> 2. Some types do want to be the source of truth of the data stored,
> instead of it being the service plugin database.
>
>
> First, let me address the possibility of a solution using one service
> plugin and multiple drivers per type:
>
>
> I think that you can overcome #1 in the instantiation of the service
> plugin to check if there are more than 1 provider active, if so you can
> just throw an exception saying you can only have 1.  I'd have to look at it
> more to see if there are any caveats to this, but I think that would work.
>
>
> For #2, assuming #1 works, then the drivers that are defined can have some
> boolean that they set that will tell the plugin whether they are the source
> of truth or not, and depending on that you can store the data in the
> service plugin's db or just pass the data along, also pass GET requests to
> the drivers as well.
>
>
I agree that those workarounds will surely works but I wonder what is the
meaning of a service plugin/type that can only support one service
provider? can't the service plugin be the service provider directly?

The reasons why I'm considering this change are :

1. I'm not sure we would have some use cases where we would be able to
choose one bgpvpn backend independently from the provider of the core
plugin (or a mech driver in the ML2 case) and/or the router plugin.
If one use ODL to manage its core resources, he won't be able to use nuage
or contrail to manage its bgpvpn connection.
The bgpvpn project is more about having a common API than having the
capacity to mix backends. At least for the moment.

2. I'm also considering that each plugin, which would be backend dependent,
could declare what features it supports through the use of extensions. Each
plugin would be a "bgpvpn" service type, and would implement the bgpvpn
extension, but some of them could extend the bgpvpn_connection resource
with other extensions also hosted in the bgpvpn project. Since some
backends only support attachment of networks to a bgpvpn_connection, others
support attachment of routers, and others both attachments, I'm considering
having an extension for each type of attachment. Then the bgpvpn plugin
declares what extensions it supports and the end user can act accordingly
depending on the scan of neutron extensions.
By moving to one plugin per backend, the load of extensions would be done
by the neutron framework, natively. We won't have to scan each service
providers to see what extensions it supports, as it is done by the ML2
extension manager.
But I agree that with your workaround, of allowing only one service
provider, we can easily scan this driver for its extensions.


> As for making a service plugin for each type, I don't see why that
> wouldn't work.  It seems a bit overkill to me though because you'd probably
> end up having 2 base classes for every service plugin type, one for using
> the service plugin database and another for the data source of truth being
> external.  Probably a better way to do this, I'm sure I'm oversimplifying.
>
You're right, and you're not oversimplifying. With this change, the bgpvpn
framework will only manage API extensions and the DB layer if needed. And
we don't want this framework to be complicated, in a first step, we just
want to have a consistent API for every backends.

> I don't see much technical reasons why you couldn't do this, though.  It's
> just inconsistent and might cause some confusion.  I'd need to spend some
> time on it to really have an educated opinion.
>
The fact that this change will lead to inconsistency between usage of each
service plugins is a valid point and might be enough to not do it and
instead limiting the bgpvpn service plugin to be able to only load one
service driver for the moment. Which is also inconsistent with some other
service plugins, but probably less.

thanks brandon.

Mathieu

Thanks,
> Brandon
> --
> *From:* Mathieu Rohon 
> *Sent:* Tuesday, August 18, 2015 7:13 AM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service
> driver
>
> Adding the related subject :)
>
> On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon 
> wrote:
>
>> Hi all,
>>
>> The current bgpvpn implementation is using the service type framework,
>> with a service plugin and one or more service providers.
>>
>> After registering the bug [1], I wonder if we would rather use a service
>> plugin per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which
>> handles API calls, instead of having one service plugin which forwards API
>

Re: [openstack-dev] [nova] compute <-> conductor and version compatibility

[Matt Riedemann]

On 8/17/2015 10:19 AM, Dan Smith wrote:

Is this documented somewhere?

I did a bit of digging and couldn't find anywhere that explicitly
required that for the J->K upgrade.  Certainly it was documented for the
I->J upgrade.


It's our model, so I don't think we need to document it for each cycle
since we don't expect it to change. We may need more general coverage
for this topic, but I don't expect the release notes to always mention it.

This isn't formal documentation, but it's relevant:

http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/

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



We have some very loose upgrade docs in the devref [1].  Under the 
"Process" section, steps 4 and 5 talk about upgrading services in order 
and says conductor (implied controller) first.  Granted we need to clean 
up this page and merge with Dan's more specific blog post, but there is 
*something* in tree docs.


[1] http://docs.openstack.org/developer/nova/upgrade.html

--

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] [Horizon] Update on Angular Identity work

[Lin Hua Cheng]

I think the table setup pattern have some opportunity for reducing code
duplication before it gets re-used by other panels..

We used to just need to write one file to define a table, now we have to
write 9 files [1].  Can we have a table directive to reduce the duplicated
code before moving forward to other panels?

-Lin

[1]
https://github.com/openstack/horizon/tree/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/table

On Tue, Aug 18, 2015 at 11:49 AM, Thai Q Tran  wrote:

> Hi everyone,
>
> Just wanted to keep everyone up to date on the angular panels work. The
> goal was to set a pattern that others can follow, to that end, there were a
> few requirements:
> 1. reusable and possibly pluggable
> 2. easy to understand
> 3. reduce code duplication
>
> These requirements don't always go hand-in-hand, and that is the primary
> reason why it is taking a bit longer. I believe we are nearing the end of
> it, here are some items remaining that I believe is crucial to finishing up
> this work.
>
> a. i18n was completed, so we need help moving gettext blobs to HTML
> templates (example patch: https://review.openstack.org/#/c/210366/ )
> volunteers are welcomed! We want others to use the translate directive as
> the main way to translate text blobs, this was why we went down this road
> using babel and angular_extractor plugin.
>
> b. transfer table supports clone feature (
> https://review.openstack.org/#/c/211345/ ). There were a lot of template
> duplications, this clone feature reduces the HTML by a considerable amount.
> Since this is something we use quite often, it made sense to invest time
> into improving it. We have had complaints that there was too much HTML
> fragments, this will address a bit of that. One of the challenge was to get
> it working with existing launch-instance, so I spent about 2 weeks making
> sure it worked well with the old code while allowing the new clone feature.
>
> c. I believe we have a pretty good pattern setup for tables. The final
> piece of the puzzle was the patterns for various actions. We have wizard
> (create user), form (edit user), confirmation dialog (delete user), and
> actions with no modal dialog (enable user). We wanted a general pattern
> that would address the requirements mentioned above. There were some
> discussions around extensibility at the midcycle that I think will fit well
> here as well (
> https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin ).
> The actions can follow a similar pattern to workflow. I believe this
> pattern would address #1 and #3 but making it easy to understand is a bit
> challenging - I think this is where documentation could help.
>
> https://review.openstack.org/#/c/202315/ and a few other patches are
> going to be ready for review soon (sometime end of this week)! Item #c is
> the most important piece, it is going to be the general pattern that people
> will use to build their angular panels with, so the more eyes we can get on
> it, the better. My aim is to get it in before the feature freeze and I
> think that is entirely possible with your help. So please help review even
> if you are not a core!
>
> Thanks
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Congress] [Murano] multiple numbers of arguments for table

[Tim Hinrichs]

Hi all,

We're contemplating a small syntax change in the Congress policy language
and wanted to see if it would cause anyone problems.

Currently you can write rules that give a single table differing numbers of
columns.  In the following example, the 'error' table has both 1 column and
2 columns.

error(vm) :- blah blah
error(vm, net) :- blah blah

We're contemplating removing this flexibility and making every table have a
fixed number of columns.  (We only support differing numbers of columns in
very special cases anyway.)

Would this cause any problems?  Murano team?

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

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Ruby Loo]

On 18 August 2015 at 13:08, Lucas Alvares Gomes 
wrote:

> HI
>
> > Hi, I'd like to make sure I understand. Is it the case that ideally, if
> we
> > could go back in time, we'd like to change the client so it defaults to
> 1.1?
>
> AFAIUI, yes
>
> > But since we can't, the next client that we ship/release will have the
> most
> > reasonable oldest version? If so, then since the most recent client
> shipped
> > is at 1.6, then I think we should put it back to 1.6 even though it is
> 1.9
> > on master. Regardless of whether there are no backwards incompatible
> changes
> > between 1.6 & 1.9 -- because we need to stick to some
> way-of-doing-things,
> > and if we use 1.9, I suspect it will be confusing. At least 1.6 was what
> we
> > had at the end of kilo.
> >
>
> The reason why I think we should release with 1.9 is because:
>
> 1) It's already on master and people may be using it already
>
> 2) It's compatible with the previous version that has been released
> already (1.6).
>
> So it won't break neither users that just get it from pip nor users
> that clone the git repository.
>

The order of my preference is 1.1 (which is unrealistic as I mention
below), 1.6 (because that's what the client had in kilo release and is the
'closest' version to the server's 1.1), then 1.9 for the reasons you
mentioned above, then 1.10 just cuz it is the last version that is
backwards compatible :-)

Devananda has a patch[0] that changes the client to 1.6, but the reviewers'
comments there point to the mailing list (here) wrt deciding what it should
be so what do other folks think?


> > What we're saying is that for M*, N*, O*, ..., the version used in the
> > client will be the higher of server's MIN_VER_STR or 1.6, right?
> >
>
> It's a suggestion, if we all agree that the minimal version (1.1) is
> the ideal version to the client to be pinned with when no other
> version is specified, how can we best warn the users that we are going
> to pin to this version for the future releases ?
>
> Maybe we don't need to do that, but would be good to discuss and have
> a consensus about it.
>

 I think 1.1 (the server's MIN_VER_STR) is the ideal version for the
client, but I think we missed the boat on that. I don't think it makes much
sense to change things so that the client uses that version in some future
release. The reason being is that kilo was released with the client
defaulting to 1.6. For everyone in cloudland not explicitly specifying a
version, they are using 1.6. And what is different in 1.6 than 1.1 -- we
renamed NOSTATE to AVAILABLE state. I don't think it is worth breaking
existing applications to deprecate/go back to 1.1.

(A separate discussion I'd like to have, is when do we want to change the
server's MIN_VER_STR from 1.1 to eg 1.6 or even gasp, 1.11 when ENROLL made
its appearance).

--ruby

[0] https://review.openstack.org/#/c/208102/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-deb] Devstack stable/juno fails to install

[Matt Riedemann]

On 8/17/2015 7:59 PM, Tony Breeds wrote:

On Mon, Aug 17, 2015 at 03:51:46PM -0500, Matt Riedemann wrote:


What version of taskflow is installed?  Cinder 2014.2.3 requires this
version of taskflow [1]:

taskflow>=0.4,<0.7.0

Which should get you taskflow 0.6.2, and taskflow 0.6.2 has this requirement
[2] for futures:

futures<=2.2.0,>=2.1.6

What version of futures is installed?  Run 'pip show futures'.


---
stack@stack01:~/projects/openstack/openstack-dev/devstack$ pip show futures
---
Metadata-Version: 2.0
Name: futures
Version: 3.0.3
Summary: Backport of the concurrent.futures package from Python 3.2
Home-page: https://github.com/agronholm/pythonfutures
Author: Alex Gronholm
Author-email: alex.gronholm+p...@nextday.fi
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires:
---

I think this is being pulled in by an uncapped dependancy in swiftclient:
---
2015-08-17 23:41:42.287 | Collecting futures>=2.1.3 (from 
python-swiftclient<=2.3.1,>=2.2.0->glance==2014.2.4.dev6)
2015-08-17 23:41:42.326 |   Using cached futures-3.0.3-py2-none-any.whl
---

I know the devstack/juno install worked on Friday last week, so something 
changed over the weekend.

Ahh perhaps this https://review.openstack.org/#/c/212652/ ?

My solution would be to cap futures in swiftclient but I don't knwo that is 
correct.

Yours Tony.



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



Yeah, g-r for stable/juno caps python-swiftclient at 2.3.1 [1] and that 
version has an uncapped dependency on futures [2].


You'd have to get a stable/juno branch created for python-swiftclient 
from the 2.3.1 tag probably, then cap futures and release that as 2.3.2. 
 You'd also have to raise the cap on swiftclient in g-r stable/juno to 
python-swiftclient>=2.2.0,<2.4.0.


[1] 
https://github.com/openstack/requirements/blob/stable/juno/global-requirements.txt#L121
[2] 
https://github.com/openstack/python-swiftclient/blob/2.3.1/requirements.txt#L1


--

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] [tripleo] Upgrades, Releases & Branches

[Steven Hardy]

On Tue, Aug 18, 2015 at 02:28:39PM -0400, James Slagle wrote:
> On Tue, Aug 18, 2015 at 2:10 PM, Steven Hardy  wrote:
> > On Mon, Aug 17, 2015 at 03:29:07PM -0400, James Slagle wrote:
> >> On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy  wrote:
> >> > Hi all,
> >> >
> >> > Recently I had some discussion with folks around the future strategy for
> >> > TripleO wrt upgrades, releases and branches, specifically:
> >> >
> >> > - How do we support a "stable" TripleO release/branch that enables folks 
> >> > to
> >> >   easily deploy the current stable release of OpenStack
> >> > - Related to the above, how do we allow development of TripleO components
> >> >   (and in particular t-h-t) to proceed without imposing undue constraints
> >> >   on what new features may be used (e.g new-for-liberty Heat features 
> >> > which
> >> >   aren't present in the current released OpenStack version)
> >> > - We're aiming to provide upgrade support, thus from and to which 
> >> > versions?
> >> >
> >> > I know historically TripleO has taken something of a developer and/or
> >> > continuous deployment model for granted, but I'd like to propose that we
> >> > revisit that discusion, such that we move towards something that's more
> >> > consumable by users/operators that are consuming the OpenStack 
> >> > coordinated
> >> > releases.
> >> >
> >> > The obvious answer is a stable branch for certain TripleO components, and
> >> > in particular for t-h-t, but this has disadvantages if we take the
> >> > OpenStack wide "no feature backports" approach - for example "upgrade
> >> > support to liberty" could be considered a feature, and many other TripleO
> >> > "features" are really more about making features of the deployed 
> >> > OpenStack
> >> > services consumable.
> >> >
> >> > I'd like propose we take a somewhat modified "release branch" approach,
> >> > which combines many of the advantages of the stable-branch model, but
> >> > allows for a somewhat more liberal approach to backports, where most 
> >> > things
> >> > are considered valid backports provided they work with the currently
> >> > released OpenStack services (e.g right now, a t-h-t release/kilo branch
> >> > would have to maintain compatibility with a kilo Heat in the undercloud)
> >>
> >> I like the idea, it seems reasonable to me.
> >>
> >> I do think we should clarify if the rule is:
> >>
> >> We *can* backport anything to release/kilo that doesn't break
> >> compatibility with kilo Heat.
> >>
> >> Or:
> >>
> >> We *must* backport anything to release/kilo that doesn't break
> >> compatibility with kilo Heat.
> >
> > I think I was envisaging something closer to the "must", but as Zane said,
> > more a "should", which if automated would become an opt-out thing, e.g
> > through a commit tag "nobackport" or whatever.
> >
> > Ideally, for the upstream branch we should probably be backporting most
> > things which don't break compatibility with the currently released
> > OpenStack services, and don't introduce gratuitous interface changes or
> > other backwards incompatibilities.
> >
> > I know our template "interfaces" are fuzzily defined but here are some
> > ideas of things we might not backport in addition to the "must work with
> > kilo" rule:
> >
> > - Removing parameters or resource types used to hook in external/optional
> >   code (e.g *ExtraConfig etc) - we should advertise these as deprecated via
> >   the descriptions, docs and release notes, then have them removed only
> >   when moving between TripleO releases (same as deprecation policy for most
> >   other projects)
> >
> > - Adding support for new services which either don't exist or weren't
> >   considered stable in the current released version
> >
> >> If it's the former, I think we'd get into a lot of subjective
> >> discussions around if we want certain things backported or not.
> >> Essentially it's the same discussion that happens for stable/*, except
> >> we consider features as well. This could become quite difficult to
> >> manage, and lead to a lot of reviewer opinionated inconsistency into
> >> what actually ends up getting backported.
> >
> > True, but this decision making ends up happening sometime regardless, e.g
> > what patches do you carry in a downstream package etc?  But you're right
> > defining the process early should help with consistency.
> >
> >>
> >> For instance, there could be a very large and disruptive feature that
> >> doesn't break compatibility at all, but some users may not want to see
> >> it in release/kilo. Or, something like the recent proposed patch to
> >> rename a bunch of templates by dropping the "-puppet". That doesn't
> >> break compatibility with a kilo Heat at all, however it could break
> >> compatibility with someone's scripts or external tooling, and might be
> >> a considered an "API" incompatible change. The consuming downstreams
> >> (RDO) may not want to consume such a change. I know we don't have any
> >> official published "API" for tripleo-heat-

Re: [openstack-dev] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

[Robert Collins]

On 19 August 2015 at 03:51, Sean Dague  wrote:

> So... I'm at Linux Con this week, meaning that things will be slow. I
> think - https://review.openstack.org/#/c/208582/ (slightly updated this
> morning) will get devstack users working again. And I agree, we really
> need devstack and the gate to be convergent on their solution here, not
> divergent.

So unless something has changed, devstack users are broken only on
Fedora - and the constraints thing won't protect them at this stage
because of two things.

Firstly, the bug isn't a cryptography bug - its a setuptools / pip
thing resulting in the .so pip installs being in the arch neutral path
rather than lib64, and this would work except that devstack also
installs python-cffi, which then masks the pip updated one. I don't
know why devstack is installing the binary package :/. This is a
Fedora platform specific bug - it doesn't show up on Ubuntu - either
because devstack doesn't install the ubuntu python-cffi package, or
because pip/setuptools on ubuntu don't have the same disconnect with
system packages in the same way. I'm not sure which.

Secondly, until we have a gate on openstack/requirements that checks
devstack-on-fedora, fedora developers will be exposed to this sort of
thing from time to time :/.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [all][api] New API Guidelines ready for cross project review

[michael mccune]

On 08/11/2015 10:28 AM, michael mccune wrote:

1. Add new guideline for HTTP Headers
https://review.openstack.org/#/c/186526/

2. Add advice on when to use POST or PUT in create
https://review.openstack.org/#/c/181912/

3. Clarify the return code when server have hard-code length limit
https://review.openstack.org/#/c/181784/


these guidelines have been merged as per the freeze process guidelines.

guidelines #1 and #2, generated comments that should be addressed in 
follow-up patches.


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] [keystone] Liberty SPFE Request - IDP Specific WebSSO

[Lance Bragstad]

Just following up the thread; this was voted on during the Keystone meeting
today and the SPFE has been granted [0].

http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2015-08-18.log.html#t2015-08-18T18:03:37

On Thu, Aug 13, 2015 at 9:49 AM, Morgan Fainberg 
wrote:

> To be fair this is pushing late into the cycle for adding a new target for
> Liberty. We already have a very large body of code that has historically
> not received consistent reviewing. My concern is that we're again rushing
> things in at the wire and will get a substandard implementation.
>
> I wont block this, but as with the other spec freeze exceptions we will
> vote at the next keystone meeting on accepting this spec freeze exception.
>
> Please make sure to add it to the weekly meeting and feel free to continue
> this discussion here on the ML to cover justifications etc.
>
> --Morgan
>
> Sent via mobile
>
> On Aug 12, 2015, at 16:20, Lance Bragstad  wrote:
>
> Hey all,
>
>
> I'd like to propose a spec proposal freeze exception for IDP Specific
> WebSSO [0].
>
> This topic has been discussed, in length, on the mailing list [1], where
> this spec has been referenced as a possible solution [2]. This would allow
> for multiple Identity Providers to use the same protocol. As described on
> the mailing list, this proposal would help with the public cloud cases for
> federated authentication workflows, where Identity Providers can't be
> directly exposed to users.
>
> The flow would look similar to what we already do for federated
> authentication [3], but it includes adding a call in step 3. Most of the
> code for step 3 already exists in Keystone, it would more or less be adding
> it to the path.
>
>
> Thanks!
>
>
> [0] https://review.openstack.org/#/c/199339/2
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/071131.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/071571.html
> [3] http://goo.gl/lLbvE1
>
> __
> OpenStack Development Mailing 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] [ironic] Re: New API for node create, specifying initial provision state

[Ruby Loo]

Apologies, forgot to add [ironic] to the subject.

On 18 August 2015 at 13:27, Ruby Loo  wrote:

> Hi,
>
> I want to start a different thread on this topic because I don't think
> this is about whether/how to do API microversions. Rather, given that we
> are going to support microversioning, how to deal with the non-backward
> compatible change in 1.11 with the ENROLL state (instead of AVAILABLE)
> being the provision state that a node is in, after being created/registered
> in ironic.
>
> (This was from 'Let's talk about API versions,
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html
> .)
>
> I want to think about this before replying but others are more than
> welcome to reply first so that I may not feel the need to reply :-)
>
> --ruby
> maybe chop off this and above when replying :-)
>
> On 17 August 2015 at 20:20, Robert Collins 
> wrote:
>
>> On 11 August 2015 at 06:13, Ruby Loo  wrote:
>> > Hi, sorry for the delay. I vote no. I understand the rationale of
>> trying to
>> > do things so that we don't break our users but that's what the
>> versioning is
>> > meant for and more importantly -- I think adding the ENROLL state is
>> fairly
>> > important wrt the lifecycle of a node. I don't particularly want to hide
>> > that and/or let folks opt out of it in the long term.
>> >
>> > From a reviewer point-of-view, my concern is me trying to remember all
>> the
>> > possible permutations/states etc that are possible to make sure that new
>> > code doesn't break existing behavior. I haven't thought out whether
>> adding
>> > this new API would make that worse or not, but then, I don't really
>> want to
>> > have to think about it. So KISS as much as we can! :)
>>
>> I'm a little surprised by this, to be honest.
>>
>> Here's why: allowing the initial state to be chosen from
>> ENROLL/AVAILABLE from the latest version of the API is precisely as
>> complex as allowing two versions of the API {old, new} where old
>> creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
>> difference I can see is that eventually someday if {old} stops being
>> supported, then and only then we can go through the code and clean
>> things up.
>>
>> It seems to me that the costs to us of supporting graceful transitions
>> for users here are:
>>
>> 1) A new version NEWVER of the API that supports node state being one
>> of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
>> AVAILABLE when not supplied.
>> 2) Supporting the initial state of AVAILABLE indefinitely rather than
>> just until we *delete* version 1.10.
>> 3) CD deployments that had rolled forward to 1.11 will need to add the
>> state parameter to their scripts to move forward to NEWVER.
>> 4) Don't default the client to the veresions between 1.10 and NEWVER
>> versions at any point.
>>
>> That seems like a very small price to pay on our side, and the
>> benefits for users are that they can opt into the new functionality
>> when they are ready.
>>
>> -Rob
>>
>> --
>> Robert Collins 
>> Distinguished Technologist
>> HP Converged Cloud
>>
>> __
>> OpenStack Development Mailing 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][bgpvpn] Service Plugin vs Service driver

[Brandon Logan]

?So let me make sure I understand this. You want to do a separate service 
plugin for what would normally be separate drivers under one service plugin.  
The reasons for this are:


1. You dont want users the ability to choose the type, you want it always to be 
the same one

2. Some types do want to be the source of truth of the data stored, instead of 
it being the service plugin database.


First, let me address the possibility of a solution using one service plugin 
and multiple drivers per type:


I think that you can overcome #1 in the instantiation of the service plugin to 
check if there are more than 1 provider active, if so you can just throw an 
exception saying you can only have 1.  I'd have to look at it more to see if 
there are any caveats to this, but I think that would work.


For #2, assuming #1 works, then the drivers that are defined can have some 
boolean that they set that will tell the plugin whether they are the source of 
truth or not, and depending on that you can store the data in the service 
plugin's db or just pass the data along, also pass GET requests to the drivers 
as well.


As for making a service plugin for each type, I don't see why that wouldn't 
work.  It seems a bit overkill to me though because you'd probably end up 
having 2 base classes for every service plugin type, one for using the service 
plugin database and another for the data source of truth being external.  
Probably a better way to do this, I'm sure I'm oversimplifying.  I don't see 
much technical reasons why you couldn't do this, though.  It's just 
inconsistent and might cause some confusion.  I'd need to spend some time on it 
to really have an educated opinion.


Thanks,
Brandon


From: Mathieu Rohon 
Sent: Tuesday, August 18, 2015 7:13 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver

Adding the related subject :)

On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon 
mailto:mathieu.ro...@gmail.com>> wrote:
Hi all,

The current bgpvpn implementation is using the service type framework, with a 
service plugin and one or more service providers.

After registering the bug [1], I wonder if we would rather use a service plugin 
per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which handles 
API calls, instead of having one service plugin which forwards API calls to a 
service driver depending on the provider chosen by the end user.

I would like to better understand what would be the main drawbacks of such a 
move apart from the fact that a deployment would be tightly coupled to a bgpvpn 
plugin, and multiple implementations of the plugin couldn't coexist.

Thanks,

Mathieu

[1]https://bugs.launchpad.net/bgpvpn/+bug/1485515

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

Re: [openstack-dev] [Horizon] Update on Angular Identity work

[Thai Q Tran]

Hi everyone,Just wanted to keep everyone up to date on the angular panels work. The goal was to set a pattern that others can follow, to that end, there were a few requirements:1. reusable and possibly pluggable2. easy to understand3. reduce code duplicationThese requirements don't always go hand-in-hand, and that is the primary reason why it is taking a bit longer. I believe we are nearing the end of it, here are some items remaining that I believe is crucial to finishing up this work.a. i18n was completed, so we need help moving gettext blobs to HTML templates (example patch: https://review.openstack.org/#/c/210366/ ) volunteers are welcomed! We want others to use the translate directive as the main way to translate text blobs, this was why we went down this road using babel and angular_extractor plugin.b. transfer table supports clone feature ( https://review.openstack.org/#/c/211345/ ). There were a lot of template duplications, this clone feature reduces the HTML by a considerable amount. Since this is something we use quite often, it made sense to invest time into improving it. We have had complaints that there was too much HTML fragments, this will address a bit of that. One of the challenge was to get it working with existing launch-instance, so I spent about 2 weeks making sure it worked well with the old code while allowing the new clone feature.c. I believe we have a pretty good pattern setup for tables. The final piece of the puzzle was the patterns for various actions. We have wizard (create user), form (edit user), confirmation dialog (delete user), and actions with no modal dialog (enable user). We wanted a general pattern that would address the requirements mentioned above. There were some discussions around extensibility at the midcycle that I think will fit well here as well ( https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin ). The actions can follow a similar pattern to workflow. I believe this pattern would address #1 and #3 but making it easy to understand is a bit challenging - I think this is where documentation could help. https://review.openstack.org/#/c/202315/ and a few other patches are going to be ready for review soon (sometime end of this week)! Item #c is the most important piece, it is going to be the general pattern that people will use to build their angular panels with, so the more eyes we can get on it, the better. My aim is to get it in before the feature freeze and I think that is entirely possible with your help. So please help review even if you are not a core!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] [neutron] New networking-calico project

[Sean M. Collins]

Are your ACLs set up properly?

https://review.openstack.org/#/admin/projects/openstack/networking-calico,access

I don't see your group - or any actual group that has rights assigned to
the repo - it's empty.

compare that to:

https://review.openstack.org/#/admin/projects/openstack/neutron,access


-- 
Sean M. Collins

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

Re: [openstack-dev] [tripleo] Upgrades, Releases & Branches

[James Slagle]

On Tue, Aug 18, 2015 at 2:10 PM, Steven Hardy  wrote:
> On Mon, Aug 17, 2015 at 03:29:07PM -0400, James Slagle wrote:
>> On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy  wrote:
>> > Hi all,
>> >
>> > Recently I had some discussion with folks around the future strategy for
>> > TripleO wrt upgrades, releases and branches, specifically:
>> >
>> > - How do we support a "stable" TripleO release/branch that enables folks to
>> >   easily deploy the current stable release of OpenStack
>> > - Related to the above, how do we allow development of TripleO components
>> >   (and in particular t-h-t) to proceed without imposing undue constraints
>> >   on what new features may be used (e.g new-for-liberty Heat features which
>> >   aren't present in the current released OpenStack version)
>> > - We're aiming to provide upgrade support, thus from and to which versions?
>> >
>> > I know historically TripleO has taken something of a developer and/or
>> > continuous deployment model for granted, but I'd like to propose that we
>> > revisit that discusion, such that we move towards something that's more
>> > consumable by users/operators that are consuming the OpenStack coordinated
>> > releases.
>> >
>> > The obvious answer is a stable branch for certain TripleO components, and
>> > in particular for t-h-t, but this has disadvantages if we take the
>> > OpenStack wide "no feature backports" approach - for example "upgrade
>> > support to liberty" could be considered a feature, and many other TripleO
>> > "features" are really more about making features of the deployed OpenStack
>> > services consumable.
>> >
>> > I'd like propose we take a somewhat modified "release branch" approach,
>> > which combines many of the advantages of the stable-branch model, but
>> > allows for a somewhat more liberal approach to backports, where most things
>> > are considered valid backports provided they work with the currently
>> > released OpenStack services (e.g right now, a t-h-t release/kilo branch
>> > would have to maintain compatibility with a kilo Heat in the undercloud)
>>
>> I like the idea, it seems reasonable to me.
>>
>> I do think we should clarify if the rule is:
>>
>> We *can* backport anything to release/kilo that doesn't break
>> compatibility with kilo Heat.
>>
>> Or:
>>
>> We *must* backport anything to release/kilo that doesn't break
>> compatibility with kilo Heat.
>
> I think I was envisaging something closer to the "must", but as Zane said,
> more a "should", which if automated would become an opt-out thing, e.g
> through a commit tag "nobackport" or whatever.
>
> Ideally, for the upstream branch we should probably be backporting most
> things which don't break compatibility with the currently released
> OpenStack services, and don't introduce gratuitous interface changes or
> other backwards incompatibilities.
>
> I know our template "interfaces" are fuzzily defined but here are some
> ideas of things we might not backport in addition to the "must work with
> kilo" rule:
>
> - Removing parameters or resource types used to hook in external/optional
>   code (e.g *ExtraConfig etc) - we should advertise these as deprecated via
>   the descriptions, docs and release notes, then have them removed only
>   when moving between TripleO releases (same as deprecation policy for most
>   other projects)
>
> - Adding support for new services which either don't exist or weren't
>   considered stable in the current released version
>
>> If it's the former, I think we'd get into a lot of subjective
>> discussions around if we want certain things backported or not.
>> Essentially it's the same discussion that happens for stable/*, except
>> we consider features as well. This could become quite difficult to
>> manage, and lead to a lot of reviewer opinionated inconsistency into
>> what actually ends up getting backported.
>
> True, but this decision making ends up happening sometime regardless, e.g
> what patches do you carry in a downstream package etc?  But you're right
> defining the process early should help with consistency.
>
>>
>> For instance, there could be a very large and disruptive feature that
>> doesn't break compatibility at all, but some users may not want to see
>> it in release/kilo. Or, something like the recent proposed patch to
>> rename a bunch of templates by dropping the "-puppet". That doesn't
>> break compatibility with a kilo Heat at all, however it could break
>> compatibility with someone's scripts or external tooling, and might be
>> a considered an "API" incompatible change. The consuming downstreams
>> (RDO) may not want to consume such a change. I know we don't have any
>> official published "API" for tripleo-heat-templates, I'm just trying
>> to think about how people consume the templates, and what they might
>> find surprising if they were to be using release/kilo.
>
> Yeah, it's a tricky one, I mean the aim of all this is to avoid having to
> maintain a fork downstream, and to improve the experien

Re: [openstack-dev] [neutron] New networking-calico project

[Neil Jerram]

No, still not, I'm afraid.


  Original Message
From: Sean M. Collins
Sent: Tuesday, 18 August 2015 19:15
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] New networking-calico project


Jenkins came back with a +1 about 20 minutes after your +1 - see if you
can +2 it now? Totally a guess.
--
Sean M. Collins

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

__
OpenStack Development Mailing 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][NFV] No weekly IRC meeting this week

[Sridhar Ramaswamy]

Heads up.

Tacker team is holding a Liberty mid-cycle meetup this week [1]. Hence we
are cancelling our weekly IRC meeting this week on Aug 20th. The meeting
will resume next week (on Aug 27th).

[1] https://etherpad.openstack.org/p/liberty-tacker-midcycle
__
OpenStack Development Mailing 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] Upgrades, Releases & Branches

[Steven Hardy]

On Mon, Aug 17, 2015 at 03:29:07PM -0400, James Slagle wrote:
> On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy  wrote:
> > Hi all,
> >
> > Recently I had some discussion with folks around the future strategy for
> > TripleO wrt upgrades, releases and branches, specifically:
> >
> > - How do we support a "stable" TripleO release/branch that enables folks to
> >   easily deploy the current stable release of OpenStack
> > - Related to the above, how do we allow development of TripleO components
> >   (and in particular t-h-t) to proceed without imposing undue constraints
> >   on what new features may be used (e.g new-for-liberty Heat features which
> >   aren't present in the current released OpenStack version)
> > - We're aiming to provide upgrade support, thus from and to which versions?
> >
> > I know historically TripleO has taken something of a developer and/or
> > continuous deployment model for granted, but I'd like to propose that we
> > revisit that discusion, such that we move towards something that's more
> > consumable by users/operators that are consuming the OpenStack coordinated
> > releases.
> >
> > The obvious answer is a stable branch for certain TripleO components, and
> > in particular for t-h-t, but this has disadvantages if we take the
> > OpenStack wide "no feature backports" approach - for example "upgrade
> > support to liberty" could be considered a feature, and many other TripleO
> > "features" are really more about making features of the deployed OpenStack
> > services consumable.
> >
> > I'd like propose we take a somewhat modified "release branch" approach,
> > which combines many of the advantages of the stable-branch model, but
> > allows for a somewhat more liberal approach to backports, where most things
> > are considered valid backports provided they work with the currently
> > released OpenStack services (e.g right now, a t-h-t release/kilo branch
> > would have to maintain compatibility with a kilo Heat in the undercloud)
> 
> I like the idea, it seems reasonable to me.
> 
> I do think we should clarify if the rule is:
> 
> We *can* backport anything to release/kilo that doesn't break
> compatibility with kilo Heat.
> 
> Or:
> 
> We *must* backport anything to release/kilo that doesn't break
> compatibility with kilo Heat.

I think I was envisaging something closer to the "must", but as Zane said,
more a "should", which if automated would become an opt-out thing, e.g
through a commit tag "nobackport" or whatever.

Ideally, for the upstream branch we should probably be backporting most
things which don't break compatibility with the currently released
OpenStack services, and don't introduce gratuitous interface changes or
other backwards incompatibilities.

I know our template "interfaces" are fuzzily defined but here are some
ideas of things we might not backport in addition to the "must work with
kilo" rule:

- Removing parameters or resource types used to hook in external/optional
  code (e.g *ExtraConfig etc) - we should advertise these as deprecated via
  the descriptions, docs and release notes, then have them removed only
  when moving between TripleO releases (same as deprecation policy for most
  other projects)

- Adding support for new services which either don't exist or weren't
  considered stable in the current released version

> If it's the former, I think we'd get into a lot of subjective
> discussions around if we want certain things backported or not.
> Essentially it's the same discussion that happens for stable/*, except
> we consider features as well. This could become quite difficult to
> manage, and lead to a lot of reviewer opinionated inconsistency into
> what actually ends up getting backported.

True, but this decision making ends up happening sometime regardless, e.g
what patches do you carry in a downstream package etc?  But you're right
defining the process early should help with consistency.

> 
> For instance, there could be a very large and disruptive feature that
> doesn't break compatibility at all, but some users may not want to see
> it in release/kilo. Or, something like the recent proposed patch to
> rename a bunch of templates by dropping the "-puppet". That doesn't
> break compatibility with a kilo Heat at all, however it could break
> compatibility with someone's scripts or external tooling, and might be
> a considered an "API" incompatible change. The consuming downstreams
> (RDO) may not want to consume such a change. I know we don't have any
> official published "API" for tripleo-heat-templates, I'm just trying
> to think about how people consume the templates, and what they might
> find surprising if they were to be using release/kilo.

Yeah, it's a tricky one, I mean the aim of all this is to avoid having to
maintain a fork downstream, and to improve the experience for folks wanting
to consume upstream tripleo directly to deploy the coordinated release.

So IMO we should consider the requirements of both those groups of users

Re: [openstack-dev] [neutron] New networking-calico project

[Sean M. Collins]

Jenkins came back with a +1 about 20 minutes after your +1 - see if you
can +2 it now? Totally a guess.
-- 
Sean M. Collins

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

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[Jay Pipes]

How about a settings.py switch that would simply allow the deployer to 
entirely disable the list users functionality?


Best,
-jay

On 08/18/2015 12:52 PM, Timur Sufiev wrote:

IMO, if that's impossible to provide Users pagination/indexing for LDAP
from technical point of view, we'd better revise the current UI of
Identity->Users, since most likely production-grade OpenStack
installations will have LDAP instead of MySQL storage. So I'm for
gathering more operators/deployers feedback on the pagination (Users
panel particularly).

I'm inclined to revising existing UI not because I think the Keystone
community is adamant in doing things the way they're going to, but
because LDAP storage backend seems to be unavoidable for large OpenStack
deployments and Horizon shouldn't ignore this fact (what's the point in
having fancy UI when it's broken for real-world installations?). Of
course, 'unavoidable' thing is open to discussion.

On Tue, Aug 18, 2015 at 6:30 AM Adam Young mailto:ayo...@redhat.com>> wrote:

On 08/17/2015 09:53 PM, David Lyle wrote:


I think we've conveniently been led off track here. The original
request/subject was regarding pagination of projects in the v3
API. Since this is purely a keystone construct it seems
implausible to me that ldap or the IdP of choice would be limiting
the ability to return a paginated list of all projects. Or groups
or domains or roles for that matter.



Yeah, SQL can support it.  LDAP assignment can't.  But that is not
going to have a long life.

With Hierarchical projects, we'll probably also have to keep nesting
in mind for how we display a project list:  do we always show a flat
list, or is a tree closer to what users expect?

Both are going to work poorly for some deployments and work well for
others.



There is no reason to punt on pagination across the API for one
resource type, which actually would also work with select
backends. Give me something that I can exhaustively list in the
API I can build from.

David

On Aug 17, 2015 10:53 AM, "Fox, Kevin M" mailto:kevin@pnnl.gov>> wrote:

1. yes, but probably only if its a short list. It may be
feasible to show it only if there are 5 or less pages, and
maybe just load all pages of data and paginate it on the
client. If too big, ask the user to refine their search? Or
always paginate to 5, and then the 6th page have a page
requesting further refinement?

2. Not sure what the difference between searching and
filtering is in this context? something like facets? If so,
probably the 5 or less thing would work here too.

3. Yes, but again, probably within a smaller set of pages?

Thanks,
Kevin

From: Kruithof, Piet [pieter.c.kruithof...@hp.com
]
Sent: Sunday, August 16, 2015 9:41 AM
To: openstack-dev@lists.openstack.org

Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon]
Pagination support for Identity dashboard entities

I like Michael’s response because it moved the thread towards
identifying actual user needs before digging into the
technical feasibility.  IMHO, it would be helpful to have a
few people on the list answer his questions:

1 - Do users want to page through search results?


2 - Do users want to page through filter results? (do they use
filter results?)


3 - If they want to page, do they want to be able to go back a
page and/or know their current page?


I understand that even if we answer “yes” to all three
questions that there could be issues around implementation,
but at least we’ll know a gap exists.


Piet Kruithof
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project

"For every complex problem, there is a solution that is
simple, neat and wrong.”

H L Menken



__
OpenStack Development Mailing 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] [nfv][telcowg] Telco Working Group meeting canceled for Wednesday August 19th

[Steve Gordon]

Hi all,

Due to a number of events going on this week (Operators 
Mid-cycle/LinuxCon/KVMForum/etc.) I am canceling the Telco Working Group 
meeting for the 19th.

Thanks!

Steve

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

Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2015-08-18 10:34:35 +0200:
> Dave Walker wrote:
> > On 17 August 2015 at 15:59, Jeremy Stanley  wrote:
> >> On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
> >> [...]
> >>> OSSA: 
> >>> For commits that correspond to vulnerability fixes.
> >> [...]
> >>
> >> I don't think that's going to be feasible. Consider the sequence
> >> with a public security vulnerability... often the OSSA number isn't
> >> assigned until after one or more backports have been approved. With
> >> some careful controls introduced into the VMT process we may be able
> >> to make sure most of these get updated commit messages before they
> >> merge, but would still need a plan to solve for the times when
> >> backported security fixes slip in without an OSSA header in the
> >> commit message.
> 
> That's actually another case where we need to be able to fix up release
> notes after the fact. So my question still stands:
> 
> > We also might need a mechanism to add to release notes when we realize
> > after the fact that a specific commit in past history warrants a
> > highlight. Would some kind of no-change commit do the trick ?
> 
> Dave suggested:
> 
> > Maybe this is a perfect use-case for git-notes?  This means the commit
> > itself isn't touched and the non-scale git-tag space isn't wasted?
> 
> It definitely seems to be the perfect match: adding notes to commits
> lets us document release notes both during and after backports, without
> altering commit messages.
> 
> The trick is that like git tags, git notes do not appear to be
> code-reviewable using Gerrit, they are directly pushed by people with
> Push Refs rights (or by Gerrit itself on merge to store approval
> details). So ideally we want to generate them from properly
> code-reviewed data.
> 
> We could have a Gerrit plugin (inspired from the reviewnotes plugin)
> that takes specific headers from commit messages and populate a
> "releasenote" git note accordingly.
> 
> For after-the-fact git notes (say, to add an OSSA reference to an
> already-merged commit), we could have a section in the
> openstack/releases proposed change that describes additional
> "releasenote" git notes to push to old commits when the change is accepted.

We could use the openstack/releases repo to track all of them, so
the process is consistent for all types of stable patches.

Within the releases repo, we want to separate the release notes
from the deliverables files, because we want to support adding notes
independent of creating a release.

OK, I think this could work, but I'm worried about by whom and when.

Would it make sense to start with something simple, like just asking
folks to write RST files with release notes in the releases repository?
That at least *captures* the data, and we can enforce it as we review
stable branch patches.

Doug

> 
> Something like:
> 
> additional-notes:
>   cc6c50ee23f336d08e4fe833070943c0025a205d:
> OSSA: 2015-022
>   fcfbf8eb0e0d42ff54bd014bc9e43f5f48bd7a68:
> Release-note: >
>   Fixing bug 1237534 actually results in a 10x performance
>   improvement listing networks connected to an instance
> 
> That way all note content is properly reviewed before they make it to
> the git notes.
> 
> Then pbr would just parse git notes instead of commit messages to
> generate releasenotes files in the code tarballs.
> 

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

Re: [openstack-dev] [all][api] New API Guidelines ready for cross project review

[michael mccune]

On 08/11/2015 10:28 AM, michael mccune wrote:

1. Add new guideline for HTTP Headers
https://review.openstack.org/#/c/186526/

2. Add advice on when to use POST or PUT in create
https://review.openstack.org/#/c/181912/

3. Clarify the return code when server have hard-code length limit
https://review.openstack.org/#/c/181784/

if the API Working Group hasn't received any further feedback, we'll
merge them on August 18.


these are slated for merge today, but each has a few comments 
surrounding minor nit-type improvements. should we merge these as is and 
create fix patches, or can we add the changes and merge?


i realize that according to our process[1], these are technically good 
to merge as there is not enough -1 consensus to stop them. i just wanted 
to ask the group before pushing ahead.


mike

[1]: http://specs.openstack.org/openstack/api-wg/process.html

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

[openstack-dev] New API for node create, specifying initial provision state

[Ruby Loo]

Hi,

I want to start a different thread on this topic because I don't think this
is about whether/how to do API microversions. Rather, given that we are
going to support microversioning, how to deal with the non-backward
compatible change in 1.11 with the ENROLL state (instead of AVAILABLE)
being the provision state that a node is in, after being created/registered
in ironic.

(This was from 'Let's talk about API versions,
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html.)

I want to think about this before replying but others are more than welcome
to reply first so that I may not feel the need to reply :-)

--ruby
maybe chop off this and above when replying :-)

On 17 August 2015 at 20:20, Robert Collins 
wrote:

> On 11 August 2015 at 06:13, Ruby Loo  wrote:
> > Hi, sorry for the delay. I vote no. I understand the rationale of trying
> to
> > do things so that we don't break our users but that's what the
> versioning is
> > meant for and more importantly -- I think adding the ENROLL state is
> fairly
> > important wrt the lifecycle of a node. I don't particularly want to hide
> > that and/or let folks opt out of it in the long term.
> >
> > From a reviewer point-of-view, my concern is me trying to remember all
> the
> > possible permutations/states etc that are possible to make sure that new
> > code doesn't break existing behavior. I haven't thought out whether
> adding
> > this new API would make that worse or not, but then, I don't really want
> to
> > have to think about it. So KISS as much as we can! :)
>
> I'm a little surprised by this, to be honest.
>
> Here's why: allowing the initial state to be chosen from
> ENROLL/AVAILABLE from the latest version of the API is precisely as
> complex as allowing two versions of the API {old, new} where old
> creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
> difference I can see is that eventually someday if {old} stops being
> supported, then and only then we can go through the code and clean
> things up.
>
> It seems to me that the costs to us of supporting graceful transitions
> for users here are:
>
> 1) A new version NEWVER of the API that supports node state being one
> of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
> AVAILABLE when not supplied.
> 2) Supporting the initial state of AVAILABLE indefinitely rather than
> just until we *delete* version 1.10.
> 3) CD deployments that had rolled forward to 1.11 will need to add the
> state parameter to their scripts to move forward to NEWVER.
> 4) Don't default the client to the veresions between 1.10 and NEWVER
> versions at any point.
>
> That seems like a very small price to pay on our side, and the
> benefits for users are that they can opt into the new functionality
> when they are ready.
>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> __
> OpenStack Development Mailing 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] New networking-calico project

[Neil Jerram]

On 17/08/15 18:47, Neil Jerram wrote:
> I'd like to announce networking-calico [...]

> Then the plan for networking-calico is that it will contain docs, an ML2
> mechanism driver, a DHCP interface driver, and a Devstack plugin for
> Calico.  These aren't yet at [10], but I will be getting on with that
> shortly, [...]

> [10] https://git.openstack.org/cgit/openstack/networking-calico
>

I've hit a Gerrit/infrastructure problem related to this, and wonder if
someone can see the problem.

I have an initial cookiecutter skeleton for networking-calico at
https://review.openstack.org/#/c/211452/, and I'd like to +2 and approve
it, but I don't see any +2 or -2 options in my Gerrit page for that
change.  I _am_ a member of the networking-calico-core group [1], so I
think I should be able to do this - but as I say, I don't see the options.

[1] https://review.openstack.org/#/admin/groups/1014,members

Can anyone see the problem?  Or am I misunderstanding what I should be
able to do?

Thanks,
Neil


__
OpenStack Development Mailing 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][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

[Steven Hardy]

On Tue, Aug 18, 2015 at 05:59:44PM +0200, Jaume Devesa wrote:
> Hi Steven/Emilien,
> 
> Thanks for the quick responses. 
> 
> On Tue, 18 Aug 2015 16:10, Steven Hardy wrote:
> > On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote:
> > 
> > I think the pattern for the templates will be similar to the Cisco ML2
> > plugins which are currently being integrated:
> > 
> > https://review.openstack.org/#/c/198754/
> > 
> > The plug-points for third-party configuration is still undergoing some
> > refinement, but the basic steps are:
> > 
> > 1. Ensure you have support in the upstream puppet modules (as mentioned by
> > Emilien), and figure out the hieradata required to drive puppet as
> > required.
> 
> Yes, we would like to be fully upstream on this.  MidoNet plugin support for
> Puppet Neutron is already done since Kilo (and backported to Juno). We do have
> in mind Emilien's request. So I think that won't be a problem.
> 
> > 2. Create a heat template which creates the hieradata, and defines
> > parameters for all configurable values, e.g like:
> > 
> > https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml
> > 
> > 3. Define a heat environment file, which wires in the template from (2) via
> > the OS::TripleO::ControllerExtraConfigPre interface:
> > 
> > https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml
> > 
> > 4. Add the hieradata file deployed via (2) to the controller hierarchy:
> > 
> > https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml
> > 
> > 5. Add conditional logic to the manifiests so the appropriate modules from
> > (1) are included when your backend is enabled:
> > 
> > https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp
> > https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp
> > 
> > Basically the way this works is the hieradata is deployed via (2) before
> > puppet runs, and the manifiest changes in (5) consumes that data when we
> > apply it during deployment.
> 
> The links and the steps to follow are so helpful! Thanks again. Couple of
> questions here:
> 
> * There is no need of `tripleo-puppet-elements`?

It depends, if your additions require additional packages to be installed,
then you may need to either add them to an existing element, or create a
new element which may be specified by those building images with
diskimage-builder, e.g so their images contain what you require.

https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller

If your integration purely requires configuration changes (and the puppet
module already exists in the image), you may not need to do anything.

> * Since the integration seems feasible, does it make sense to start opening a
>   blueprint and start working on it? 

Absolutely, a blueprint is probably a good idea (although tbh these haven't
been strictly required lately..) summarising the required changes, then you
can use the examples I linked to work on the template changes.

> > No, we're moving away from tuskar and it's not required for third-party
> > integration such as described above (it's also not covered in CI).
> > 
> > Speaking of CI, it'd be good to discuss how you plan to ensure your stuff
> > stays working, as clearly we don't have the resources in upstream CI to
> > test it, having third-party CI jobs vote on TripleO changes would be one
> > way to solve this, but AFAIK we don't yet have a process in place to enable
> > this.
> 
> Even if there is not an official Third Party methodology, it wouldn't be so 
> hard
> to add a Jenkins job on our infrastructure to listen upstream gerrit events 
> and
> make comments instead of voting, right? (maybe I am speaking so quickly, I can
> not image right now how a TripleO Jenkins job look like...)

Yes, this was exactly what I had in mind - it'd be great if we could get
some sort of non-voting comments from those contributing third-party
additions - I know this pattern works well for other projects, so I guess
the same approach for TripleO may be reasonable as well.

Steve

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

[openstack-dev] [Monasca] Minutes for Monasca 8-18-2015

[Hochmuth, Roland M]

Minutes for the Monasca Weekly Meeting 8-18-2015.

https://etherpad.openstack.org/p/Monasca_Weekly_Meeting_8-18-2015

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

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Lucas Alvares Gomes]

HI

> Hi, I'd like to make sure I understand. Is it the case that ideally, if we
> could go back in time, we'd like to change the client so it defaults to 1.1?

AFAIUI, yes

> But since we can't, the next client that we ship/release will have the most
> reasonable oldest version? If so, then since the most recent client shipped
> is at 1.6, then I think we should put it back to 1.6 even though it is 1.9
> on master. Regardless of whether there are no backwards incompatible changes
> between 1.6 & 1.9 -- because we need to stick to some way-of-doing-things,
> and if we use 1.9, I suspect it will be confusing. At least 1.6 was what we
> had at the end of kilo.
>

The reason why I think we should release with 1.9 is because:

1) It's already on master and people may be using it already

2) It's compatible with the previous version that has been released
already (1.6).

So it won't break neither users that just get it from pip nor users
that clone the git repository.

> What we're saying is that for M*, N*, O*, ..., the version used in the
> client will be the higher of server's MIN_VER_STR or 1.6, right?
>

It's a suggestion, if we all agree that the minimal version (1.1) is
the ideal version to the client to be pinned with when no other
version is specified, how can we best warn the users that we are going
to pin to this version for the future releases ?

Maybe we don't need to do that, but would be good to discuss and have
a consensus about it.

>
> Hey Lucas, Maybe I missed something about the client. If no version is
> specified to the (next-released) client, won't it use 1.6? How are we going
> to move it back to 1.1?
>

Yeah *right now* with the last released version if you don't specify a
version it will use 1.6. With the current code in the git repository
the version will used will be 1.9 if no other is specified.

About how we are going to move it back was my question as well. If we
all agree in moving it to 1.1 when no version is specified how we can
best warn the users that we are going to do that? Since it might break
their workflow. Maybe we shouldn't move it back, but let's keep the
conversation going so we can solve this.

Cheers,
Lucas

__
OpenStack Development Mailing 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] [libvirt-vif] Extend vhost-user interface to support Cisco Nexus 1000v.

[Kyle Mestery]

On Tue, Aug 18, 2015 at 11:48 AM, Kiran Chunduri 
wrote:

> Hello All,
> We would like to extend the nova 'vhost-user' plug API to attach the port
> to Cisco Nexus 1000v, which supports vhost-user interface. Currently the
> plug-API supports attaching to OVS. The code I'm referring to is
> 'plug_vhostuser()' API in 'nova/virt/libvirt/vif.py'.
>
> I would like to submit changes for this. But One of my colleague mentioned
> there is a proposal to make the NOVA VIF driver more generic. Can some one
> please elaborate on this (or) point to blue-print? I would like to look and
> discuss on the proposal.
>
>
This was discussed at the nova mid-cycle, and the plan of record is for Jay
Pipes to push his os_vif repo [1] out for review once he addresses some
feedback he's received already. This will make it easier to do what you're
looking to do Kiran.

Thanks,
Kyle

[1] https://github.com/jaypipes/os_vif


> thanks in advance,
> Kiran
>
> __
> OpenStack Development Mailing 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] [stable] [infra] How to auto-generate stable release notes

[Jeremy Stanley]

On 2015-08-18 10:34:35 +0200 (+0200), Thierry Carrez wrote:
> Dave Walker wrote:
[...]
> > Maybe this is a perfect use-case for git-notes?  This means the commit
> > itself isn't touched and the non-scale git-tag space isn't wasted?
> 
> It definitely seems to be the perfect match: adding notes to commits
> lets us document release notes both during and after backports, without
> altering commit messages.
> 
> The trick is that like git tags, git notes do not appear to be
> code-reviewable using Gerrit, they are directly pushed by people with
> Push Refs rights (or by Gerrit itself on merge to store approval
> details). So ideally we want to generate them from properly
> code-reviewed data.
[...]

Well, that's not the _only_ challenge with git notes. Unlike tags,
they're not easily cloned/fetched from a remote (you need to modify
your local configuration to explicitly fetch their refspace).

> Then pbr would just parse git notes instead of commit messages to
> generate releasenotes files in the code tarballs.

It strikes me as an over-specialized feature for PBR. Basically
unless the end user modifies their local Git configuration, they
won't have a copy of these Git notes and so their PBR-generated
release notes would be substantially more hollow (or nonexistent?)
than those we're publishing. We can of course work around this in
our own automation, but at that point why bother to teach PBR about
Git notes at all?
-- 
Jeremy Stanley

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

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[Timur Sufiev]

IMO, if that's impossible to provide Users pagination/indexing for LDAP
from technical point of view, we'd better revise the current UI of
Identity->Users, since most likely production-grade OpenStack installations
will have LDAP instead of MySQL storage. So I'm for gathering more
operators/deployers feedback on the pagination (Users panel particularly).

I'm inclined to revising existing UI not because I think the Keystone
community is adamant in doing things the way they're going to, but because
LDAP storage backend seems to be unavoidable for large OpenStack
deployments and Horizon shouldn't ignore this fact (what's the point in
having fancy UI when it's broken for real-world installations?). Of course,
'unavoidable' thing is open to discussion.

On Tue, Aug 18, 2015 at 6:30 AM Adam Young  wrote:

> On 08/17/2015 09:53 PM, David Lyle wrote:
>
> I think we've conveniently been led off track here. The original
> request/subject was regarding pagination of projects in the v3 API. Since
> this is purely a keystone construct it seems implausible to me that ldap or
> the IdP of choice would be limiting the ability to return a paginated list
> of all projects. Or groups or domains or roles for that matter.
>
>
> Yeah, SQL can support it.  LDAP assignment can't.  But that is not going
> to have a long life.
>
> With Hierarchical projects, we'll probably also have to keep nesting in
> mind for how we display a project list:  do we always show a flat list, or
> is a tree closer to what users expect?
>
> Both are going to work poorly for some deployments and work well for
> others.
>
>
> There is no reason to punt on pagination across the API for one resource
> type, which actually would also work with select backends. Give me
> something that I can exhaustively list in the API I can build from.
>
> David
> On Aug 17, 2015 10:53 AM, "Fox, Kevin M"  wrote:
>
>> 1. yes, but probably only if its a short list. It may be feasible to show
>> it only if there are 5 or less pages, and maybe just load all pages of data
>> and paginate it on the client. If too big, ask the user to refine their
>> search? Or always paginate to 5, and then the 6th page have a page
>> requesting further refinement?
>>
>> 2. Not sure what the difference between searching and filtering is in
>> this context? something like facets? If so, probably the 5 or less thing
>> would work here too.
>>
>> 3. Yes, but again, probably within a smaller set of pages?
>>
>> Thanks,
>> Kevin
>> 
>> From: Kruithof, Piet [pieter.c.kruithof...@hp.com]
>> Sent: Sunday, August 16, 2015 9:41 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support
>> for Identity dashboard entities
>>
>> I like Michael’s response because it moved the thread towards identifying
>> actual user needs before digging into the technical feasibility.  IMHO, it
>> would be helpful to have a few people on the list answer his questions:
>>
>> 1 - Do users want to page through search results?
>>
>>
>> 2 - Do users want to page through filter results? (do they use filter
>> results?)
>>
>>
>> 3 - If they want to page, do they want to be able to go back a page
>> and/or know their current page?
>>
>>
>> I understand that even if we answer “yes” to all three questions that
>> there could be issues around implementation, but at least we’ll know a gap
>> exists.
>>
>>
>> Piet Kruithof
>> Sr UX Architect, HP Helion Cloud
>> PTL, OpenStack UX project
>>
>> "For every complex problem, there is a solution that is simple, neat and
>> wrong.”
>>
>> H L Menken
>>
>>
>> __
>> OpenStack Development Mailing 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: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?sub

[openstack-dev] [nova] [libvirt-vif] Extend vhost-user interface to support Cisco Nexus 1000v.

[Kiran Chunduri]

Hello All,
We would like to extend the nova 'vhost-user' plug API to attach the port
to Cisco Nexus 1000v, which supports vhost-user interface. Currently the
plug-API supports attaching to OVS. The code I'm referring to is
'plug_vhostuser()' API in 'nova/virt/libvirt/vif.py'.

I would like to submit changes for this. But One of my colleague mentioned
there is a proposal to make the NOVA VIF driver more generic. Can some one
please elaborate on this (or) point to blue-print? I would like to look and
discuss on the proposal.

thanks in advance,
Kiran
__
OpenStack Development Mailing 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][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

[Jaume Devesa]

Hi Steven/Emilien,

Thanks for the quick responses. 

On Tue, 18 Aug 2015 16:10, Steven Hardy wrote:
> On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote:
> 
> I think the pattern for the templates will be similar to the Cisco ML2
> plugins which are currently being integrated:
> 
> https://review.openstack.org/#/c/198754/
> 
> The plug-points for third-party configuration is still undergoing some
> refinement, but the basic steps are:
> 
> 1. Ensure you have support in the upstream puppet modules (as mentioned by
> Emilien), and figure out the hieradata required to drive puppet as
> required.

Yes, we would like to be fully upstream on this.  MidoNet plugin support for
Puppet Neutron is already done since Kilo (and backported to Juno). We do have
in mind Emilien's request. So I think that won't be a problem.

> 2. Create a heat template which creates the hieradata, and defines
> parameters for all configurable values, e.g like:
> 
> https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml
> 
> 3. Define a heat environment file, which wires in the template from (2) via
> the OS::TripleO::ControllerExtraConfigPre interface:
> 
> https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml
> 
> 4. Add the hieradata file deployed via (2) to the controller hierarchy:
> 
> https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml
> 
> 5. Add conditional logic to the manifiests so the appropriate modules from
> (1) are included when your backend is enabled:
> 
> https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp
> https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp
> 
> Basically the way this works is the hieradata is deployed via (2) before
> puppet runs, and the manifiest changes in (5) consumes that data when we
> apply it during deployment.

The links and the steps to follow are so helpful! Thanks again. Couple of
questions here:

* There is no need of `tripleo-puppet-elements`?
* Since the integration seems feasible, does it make sense to start opening a
  blueprint and start working on it? 

> 
> No, we're moving away from tuskar and it's not required for third-party
> integration such as described above (it's also not covered in CI).
> 
> Speaking of CI, it'd be good to discuss how you plan to ensure your stuff
> stays working, as clearly we don't have the resources in upstream CI to
> test it, having third-party CI jobs vote on TripleO changes would be one
> way to solve this, but AFAIK we don't yet have a process in place to enable
> this.

Even if there is not an official Third Party methodology, it wouldn't be so hard
to add a Jenkins job on our infrastructure to listen upstream gerrit events and
make comments instead of voting, right? (maybe I am speaking so quickly, I can
not image right now how a TripleO Jenkins job look like...)

> 
> Let us know if you need any further help - you can drop in to #tripleo on
> Freenode to discuss :)

I'm already there :)

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

Regards!

-- 
Jaume Devesa
Software Engineer at Midokura

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

Re: [openstack-dev] [puppet] weekly meeting #47

[Emilien Macchi]

On 08/16/2015 11:11 PM, Emilien Macchi wrote:
> Hello,
> 
> Here's an initial agenda for our weekly meeting, Tuesday at 1500 UTC
> in #openstack-meeting-4:
> 
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150818
> 
> Please add additional items you'd like to discuss.
> If our schedule allows it, we'll make bug triage during the meeting.
> 

We did our meeting, you can now read the notes:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-18-15.00.html

Have a great day,
-- 
Emilien Macchi



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] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

[Sean Dague]

On 08/14/2015 02:52 AM, Chris Dent wrote:
> On Fri, 14 Aug 2015, Clint Byrum wrote:
> 
>> The same is true for these bugs. Yes they're real, yes more orgs should
>> devote developers to fixing them.
> 
> This may be the root of my concern and something that we're going to
> have to address sooner than later.
> 
>> Your concerns are valid and appreciated. However, I think the side
>> effect of not setting it is wasting developer time on a large scale. The
>> side effect of setting it is putting that work into a queue which an
>> appropriately sized subset of developers can manage.
> 
> Makes sense, for the most part. Thanks to you and Robert for taking
> the thread through its paces and getting the thinking out in the
> open.

So... I'm at Linux Con this week, meaning that things will be slow. I
think - https://review.openstack.org/#/c/208582/ (slightly updated this
morning) will get devstack users working again. And I agree, we really
need devstack and the gate to be convergent on their solution here, not
divergent.

-Sean

-- 
Sean Dague
http://dague.net



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] [congress] [murano] Congress jenkins job is failing

[Tim Hinrichs]

Hi Filip,

I just submitted a revert of the problematic change.  Once it merges, all
should be well again.  Sorry for the trouble.

Tim

On Tue, Aug 18, 2015 at 7:57 AM Tim Hinrichs  wrote:

> Looks like we merged a database schema change without the migration
> script.  I'm on it.  (We'll get our tempest tests running in gate again
> ASAP.)
>
> Tim
>
>
> On Tue, Aug 18, 2015 at 7:36 AM Filip Blaha  wrote:
>
>> Hi Congress team.
>>
>> Our jenkins job testing integration congress and murano is failing.
>> Congress fails to start on some DB error [1] . Does anyone know what
>> could be the problem?
>>
>> [1]
>>
>> http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033
>>
>> Thanks
>> Filip
>>
>> __
>> OpenStack Development Mailing 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] API: Question on 'Retry-After': 0 in HTTPForbidden

[Chen CH Ji]

When doing patch[1] Ken'ichi raise a good suggestion on not raise
Retry-After according to [2]

seems nova also when doing create[3] and resize[4] a server nova may raise
those, too
is this a bug or something made on purpose? Thanks

[1]
https://review.openstack.org/#/c/180469/5/nova/api/openstack/compute/tenant_networks.py
[2]http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
[3]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L591
[4]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L846

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

[Asselin, Ramy]

Rick,

These files are missing newlines i.e. unreadable for me: [1] [2] [3]

Out of curiosity, any particular reason you don't set up a log server like 
OpenStack Infra?
I have a script to do that [4], which uses the upstream common solution [5]

Ramy

[1] 
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/devstacklog.txt.gz
[2] 
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/etc/cinder/cinder.conf.txt.gz
[3] 
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/screen-c-vol.txt.gz
[4] 
https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_log_server.sh
]5] 
http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/manifests/logserver.pp



-Original Message-
From: Rick Chen [mailto:rick.c...@prophetstor.com] 
Sent: Monday, August 17, 2015 8:22 AM
To: 'Mike Perez'
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

HI Mike:
I completed to refine our CI configuration to follow Ramy's comments. 
Does any missed or other attention I need respect?

[1] Add "export DEVSTACK_GATE_TEMPEST_REGEX=volume" to verify all 
cinder volume testing.
[2] Add each service configuration in the log.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
vm-tempest-cinder-ci/5100/logs/etc/
[3] Add email alert when the devstack build failed to instead of you 
notify to me.
[4] Integrate VMware snapshot revert feature in the Jenkins master to 
clean CI slave machine OS environment that avoid the devstack building failed 
due to previous devstack garbage configuration.
[5] Latest CI result for you reference.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
vm-tempest-cinder-ci/5100/logs/
http://download.prophetstor.com/prophetstor_ci/

[6] Logs need to be browsable online.
Add Rewrite module and rule in the apache configuration.

my gerrit account:  prophetstor-ci
   gerrit account email:prophetstor...@prophetstor.com

Many thanks.

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com]
Sent: Friday, August 14, 2015 11:41 PM
To: Rick Chen 
Cc: openstack-dev@lists.openstack.org
Subject: Re: [cinder] [third-party]RE: [OpenStack-Infra] ProphetStor CI account

On 09:44 Aug 14, Rick Chen wrote:
> HI Mike:
>   Sorry again, I already add email alert agent in our CI Jenkins
server 
> to capture each failed build result.
>   [1] -
> http://lists.openstack.org/pipermail/third-party-announce/2015-June/00
> 0192.h
> tml
>   [2] -
> http://lists.openstack.org/pipermail/third-party-announce/2015-June/00
> 0193.h
> tml
>   Solution 1: Our Jenkins client machine is vmware machine, I already 
> add snapshot revert script in the Jenkins Job script. Each git review job
> trigger the client will revert to  clean environment
> to solve this problem.
>   Solution 2: I don't know whiched changed to make keystone "unable to

> import pastedeploy". So I try to uninstall python-pastedeploy package 
> in the local to solve some
>issue about unable to build devstack issue.
>   Sorry again to disturb you.

Rick,

I looked at your CI results directory [1], but it looks like the last time this 
ran was on July 28th according to the last modified dates. This should be 
actively running even if you account is disabled from leaving comments, so I 
can verify from the logs things are running fine again.

In addition, see Ramy's comments with issues with the CI [2].

[1] - http://download.prophetstor.com/prophetstor_ci/?C=M;O=A
[2] -
http://lists.openstack.org/pipermail/openstack-infra/2015-August/003057.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

__
OpenStack Development Mailing 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][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

[Steven Hardy]

On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote:
> Hi all,
> 
> We in Midokura are considering to collaborate on TripleO to provide MidoNet 
> as a
> backend technology for Neutron in the overcloud.
> 
> We haven't found any vendor plugin image defined on the
> `tripleo-puppet-elements` nor heat template in the `tripleo-heat-templates`...
> So my first question is: Is there willingness from the TripleO folks to accept
> code to deploy third-party vendors?  Alternatively (although not desirable): 
> is
> there any plugin system to work out of the tree?
> 
> I'm a noob on TripleO, so I would need some guidance for next steps to follow 
> to
> achieve our goal. I understand that work should be done on these three 
> projects:
> 
>  * `tripleo-puppet-elements`: we do have a puppet module to configure 
> MidoNet, I
> understand an image to install the packages will be needed.
>  * `tripleo-heat-templates`: MidoNet and Neutron specific templates.

I think the pattern for the templates will be similar to the Cisco ML2
plugins which are currently being integrated:

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

The plug-points for third-party configuration is still undergoing some
refinement, but the basic steps are:

1. Ensure you have support in the upstream puppet modules (as mentioned by
Emilien), and figure out the hieradata required to drive puppet as
required.

2. Create a heat template which creates the hieradata, and defines
parameters for all configurable values, e.g like:

https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml

3. Define a heat environment file, which wires in the template from (2) via
the OS::TripleO::ControllerExtraConfigPre interface:

https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml

4. Add the hieradata file deployed via (2) to the controller hierarchy:

https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml

5. Add conditional logic to the manifiests so the appropriate modules from
(1) are included when your backend is enabled:

https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp
https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp

Basically the way this works is the hieradata is deployed via (2) before
puppet runs, and the manifiest changes in (5) consumes that data when we
apply it during deployment.

>  * `tuskar`?: will we need tuskar as well?

No, we're moving away from tuskar and it's not required for third-party
integration such as described above (it's also not covered in CI).

Speaking of CI, it'd be good to discuss how you plan to ensure your stuff
stays working, as clearly we don't have the resources in upstream CI to
test it, having third-party CI jobs vote on TripleO changes would be one
way to solve this, but AFAIK we don't yet have a process in place to enable
this.

Let us know if you need any further help - you can drop in to #tripleo on
Freenode to discuss :)

Steve

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

Re: [openstack-dev] [congress] [murano] Congress jenkins job is failing

[Tim Hinrichs]

Looks like we merged a database schema change without the migration
script.  I'm on it.  (We'll get our tempest tests running in gate again
ASAP.)

Tim


On Tue, Aug 18, 2015 at 7:36 AM Filip Blaha  wrote:

> Hi Congress team.
>
> Our jenkins job testing integration congress and murano is failing.
> Congress fails to start on some DB error [1] . Does anyone know what
> could be the problem?
>
> [1]
>
> http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033
>
> Thanks
> Filip
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

[Emilien Macchi]

On 08/18/2015 10:19 AM, Jaume Devesa wrote:
> Hi all,
> 
> We in Midokura are considering to collaborate on TripleO to provide MidoNet 
> as a
> backend technology for Neutron in the overcloud.
> 
> We haven't found any vendor plugin image defined on the
> `tripleo-puppet-elements` nor heat template in the `tripleo-heat-templates`...
> So my first question is: Is there willingness from the TripleO folks to accept
> code to deploy third-party vendors?  Alternatively (although not desirable): 
> is
> there any plugin system to work out of the tree?
> 
> I'm a noob on TripleO, so I would need some guidance for next steps to follow 
> to
> achieve our goal. I understand that work should be done on these three 
> projects:
> 
>  * `tripleo-puppet-elements`: we do have a puppet module to configure 
> MidoNet, I
> understand an image to install the packages will be needed.
>  * `tripleo-heat-templates`: MidoNet and Neutron specific templates.

For this part, please consider using openstack/puppet-neutron:
https://github.com/openstack/puppet-neutron/blob/master/manifests/plugins/midonet.pp

TripleO Heat templates tent to use 100% upstream modules, and not custom
modules or forks.
If you miss some configuration parameters in puppet-neutron, please
submit a patch accordingly.

>  * `tuskar`?: will we need tuskar as well?
> 
> Am I right?
> 
> Cheers,
> 

-- 
Emilien Macchi



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] [zaqar] Ryan Brown to join Zaqar's reviewers team

[Victoria Martínez de la Cruz]

+1

So glad to hear about this :)

Ryan has been a great addition to the Zaqar team.

His reviews are very useful and he is always willing to share his knowledge
with everyone in Zaqar's IRC channel.

Thanks Ryan!

All the best,

Victoria

2015-08-17 4:45 GMT-03:00 Flavio Percoco :

> Greetings,
>
> I'm delighted to announce that Ryan Brown (ryansb) has accepted to
> join Zaqar's core-reviewers team.
>
> After our last summit (Vancouver), Ryan has dedicated a significant
> amount of time to the project by reviewing patches, which has helped
> the team to keep things consistent.
>
> Ryan has demonstrated he's familiar with the code base and he has also
> provided valuable support on IRC and reviews not only to existing
> members but also to newcomers. This has increased everyone's trust on
> him to the point his feedback is many times requested on general
> discussions.
>
> I believe Ryan would be a great addition to our team and I'm happy he
> has accepted to join.
>
> Unless someone disagrees with the above, I'll proceed to give him the
> required permissions on the project.
>
> Feedback welcome from anyone at anytime. However, this thread will
> remain valid until Friday, August 21st.
>
> Thanks, Ryan. Keep it up.
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [congress] [murano] Congress jenkins job is failing

[Filip Blaha]

Hi Congress team.

Our jenkins job testing integration congress and murano is failing. 
Congress fails to start on some DB error [1] . Does anyone know what 
could be the problem?


[1] 
http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033


Thanks
Filip

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

Re: [openstack-dev] [OpenStack-Infra] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.

[Asselin, Ramy]

HI Abhi,

There are two ways to build images. The preferred way is to use Disk Image 
Builder (DIB).
These images are built on the same VM that nodepool is run.
When you start nodepool, it will automatically do this for you.
The instructions explain how to do it ‘manually’ which is helpful for debugging 
issues, especially the first time you setup.

Ramy

From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
Sent: Monday, August 17, 2015 11:32 PM
To: Remo Mattei
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-in...@lists.openstack.org
Subject: Re: [OpenStack-Infra] [openstack-infra][third-paty][CI][nodepool]Using 
Nodepool for creating slaves.

Hi Remo,

I got the solution for creating images, but my question is do we need to create 
the images in CI master VM or some other VM?

On Tue, Aug 18, 2015 at 11:32 AM, Remo Mattei 
mailto:r...@italy1.com>> wrote:
There is a webex scheduled for this topic you want to check it out go to 
Solinea.com

Remo

Inviato da iPhone

Il giorno 18 ago 2015, alle ore 07:41, Abhishek Shrivastava 
mailto:abhis...@cloudbyte.com>> ha scritto:
Hi Folks,

I was going through Ramy's guide for setting up CI, there I found out the 
following:

  *   
https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves
But I don't get the fact on how to create the image, also what major settings 
need to be done to make the config perfect for use. Can anyone help me with 
that?

--
[Image removed by sender.]
Thanks & Regards,
Abhishek
Cloudbyte Inc.
!DSPAM:1,55d2c5ef145828302144768!
___
OpenStack-Infra mailing list
openstack-in...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


!DSPAM:1,55d2c5ef145828302144768!



--
[Image removed by sender.]
Thanks & Regards,
Abhishek
Cloudbyte 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] [nova] should we allow overcommit for a single VM?

[Chris Friesen]

On 08/18/2015 06:56 AM, Nikola Đipanov wrote:

On 08/17/2015 08:22 PM, Chris Friesen wrote:



The basic question is, if a host has X CPUs in total for VMs, and a
single instance wants X+1 vCPUs, should we allow it?  (Regardless of
overcommit ratio.)  There is also an equivalent question for RAM.

Currently we have two different answers depending on whether numa
topology is involved or not.  Should we change one of them to make it
consistent with the other?  If so, a) which one should we change, and b)
how would we do that given that it results in a user-visible behaviour
change?  (Maybe a microversion, even though the actual API doesn't
change, just whether the request passes the scheduler filter or not?)



I would say that the "correct" behavior is what NUMA fitting logic does,
and that is to not allow instance to over-commit against itself, and we
should fix "normal" (non-NUMA) over-commit. Allowing the instance to
over-commit against itself does not make a lot of sense, however it is
not something that is likely to happen that often in real world usage -
I would imagine operators are unlikely to create flavors larger than
compute hosts.


This is a good point, in any "real" deployment it likely won't be an issue.  We 
only ran into it because we were testing on a minimal-sized compute node running 
in a VM on a designer box.



I am not sure that this has anything to do with the API thought. This is
mostly a Nova internal implementation detail. Any nova deployment can
fail to boot an instance for any number of reasons, and this does not
affect the API response of the actual boot request.


Arguably it would be changing the behaviour of a boot request.  Currently it 
would pass the scheduler and boot up, and we're talking about making it fail the 
scheduler filter.  That's an externally-visible change in behaviour.  (But as 
you say it's unlikely that it will be hit in the real world.)


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] [Ironic] Functional tests for ironicclient

[Jay Pipes]

On 08/18/2015 09:04 AM, Anton Arefiev wrote:

Hi folks,

We have plans to write functional tests for ironicclient. And  the
following question arose :

In current realization, functional test environment uses ironicclient
api directly(client managers), this approach has one problem - it
doesn't include command-line interface code. So it would be better to
use tempest-lib for this. It makes call to ironic with Popen, and has
code for parsing results.


Yeah, both approaches have value. If there are no tests in Tempest 
currently that use the python-ironicclient as a CLI tool (via Popen 
calls), then yes, I would think that would be a welcome addition.


Best,
-jay

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

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor for core

[Duncan Thomas]

+1
On 17 Aug 2015 18:51, "Ivan Kolodyazhny"  wrote:

> +1.
>
> Gorka, Thanks for your contribution!
>
> Regards,
> Ivan Kolodyazhny,
> Web Developer,
> http://blog.e0ne.info/,
> http://notacash.com/,
> http://kharkivpy.org.ua/
>
> On Sat, Aug 15, 2015 at 6:25 AM, John Griffith 
> wrote:
>
>>
>>
>> On Fri, Aug 14, 2015 at 6:06 PM, Walter A. Boring IV <
>> walter.bor...@hp.com> wrote:
>>
>>> +1
>>>
 It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

 Gorka's contributions to Cinder core have been much apprecated:


 https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

 60/90 day review stats:

 http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
 http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

 Cinder core, please reply with a +1 for approval. This will be left
 open until August 19th. Assuming there are no objections, this will go
 forward after voting is closed.


>>>
>>>
>>> __
>>> OpenStack Development Mailing 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​
>>
>>
>> __
>> OpenStack Development Mailing 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] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

[Jaume Devesa]

Hi all,

We in Midokura are considering to collaborate on TripleO to provide MidoNet as a
backend technology for Neutron in the overcloud.

We haven't found any vendor plugin image defined on the
`tripleo-puppet-elements` nor heat template in the `tripleo-heat-templates`...
So my first question is: Is there willingness from the TripleO folks to accept
code to deploy third-party vendors?  Alternatively (although not desirable): is
there any plugin system to work out of the tree?

I'm a noob on TripleO, so I would need some guidance for next steps to follow to
achieve our goal. I understand that work should be done on these three projects:

 * `tripleo-puppet-elements`: we do have a puppet module to configure MidoNet, I
understand an image to install the packages will be needed.
 * `tripleo-heat-templates`: MidoNet and Neutron specific templates.
 * `tuskar`?: will we need tuskar as well?

Am I right?

Cheers,

-- 
Jaume Devesa
Software Engineer at Midokura

__
OpenStack Development Mailing 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] extension implemented by multiple plugins

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/18/2015 03:11 PM, Bence Romsics wrote:
> Hi Ihar,
> 
> Thank you. Just rebased my patch and following the example of the
> qos feature now I can start neutron-server with both the service
> plugin and the ml2 extension driver loaded. However I have noticed
> that I can no longer mark the extension driver as implementing the
> extension alias (the 'extension_alias' property seems to be better
> not used, or I still have the same error). Is that intentional?
> 

I think the assumption is that only one plugin is capable of
implementing an extension. We only allowed to implement no extensions
at all. If you think we should allow multiple plugins to claim support
for the same extension, then it's an additional use case on top of
what we needed in qos. Why do you need it?

BTW feature/qos was merged in master yesterday, so it's now available
for all patches.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV0zrZAAoJEC5aWaUY1u57DIAIAJG+U3sVI/ejvEmETEtbINH+
mm8IFhpwoSzMNcRKfrlobgmu4R/+saGfQsUaQHjh4ko7PVq2eDH9sMPlHjVZXUGi
x5Rt7gKuFCXsPLyXybjAaaWQjI/hO65/V7D1xwQceRl9FL6kSjgxoasu5ufGUR4j
ZMmp0f9nN8v7VVHynhLq0FEYMqMs0fylO2hnyJKyJUk26Xd1GZqv/58jAl6RaB3Z
LzE6Qd6yO0R4ekEhL4DhBbf3+J59ljDhgCbCvScKiL83IZb0FT4vcYMvuHIKezHt
c23ImDJjz9ZCCld0ah39/jEcqOWj8IM41L/1Qjwdk/Fn/s1CUtFY1vJ28z8IOgg=
=rMZ7
-END PGP SIGNATURE-

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

Re: [openstack-dev] [neutron] extension implemented by multiple plugins

[Bence Romsics]

Hi Ihar,

Thank you. Just rebased my patch and following the example of the qos
feature now I can start neutron-server with both the service plugin
and the ml2 extension driver loaded. However I have noticed that I can
no longer mark the extension driver as implementing the extension
alias (the 'extension_alias' property seems to be better not used, or
I still have the same error). Is that intentional?

Cheers,
Bence

On Mon, Aug 17, 2015 at 4:46 PM, Ihar Hrachyshka  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 08/17/2015 04:35 PM, Bence Romsics wrote:
>> Hi All,
>>
>> How do I implement one extension by two plugins?
>>
>> If I extend the API by: * a first class resource, and * attributes
>> to an already existing resource (the port resource in my case).
>>
>> These two parts don't make sense without each other, so I'd like
>> to keep this as one extension, not two.
>>
>
> That's exactly what we needed in feature/qos: we have new QoS policy
> and rules objects, and we extend networks and ports with qos_policy_id.
>
>> Then naturally I'd like to implement: * the first class resource as
>> a service plugin, and * the new port attributes as an ml2 extension
>> driver.
>>
>> And straightforwardly I put the same extension alias into both the
>> service plugin and the ml2 extension driver. Then I get this
>> error:
>>
>> File "/opt/stack/neutron/neutron/manager.py", line 199, in
>> _load_service_plugins ValueError: Multiple plugins for service
>> TRUNK_PORT were configured
>
> Indeed it does not currently allow it. But in feature/qos, we solved
> it as in line 760:
>
> https://review.openstack.org/#/c/203105/6/neutron/plugins/ml2/managers.p
> y
>
> And the feature/qos branch is scheduled to merge back into master in
> next days: https://review.openstack.org/212170
>
> So you can base your work on top of the merge patch and claim problem
> solved. :)
>
> Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJV0fO1AAoJEC5aWaUY1u57SgEIAJYy3UAjqT4NXF8CdNfy3jcv
> 5dw4fqktjlj0yaiOOGM+J98vi3wVTnz+qQsk+jkS5M/0hySYQyo0M8JPF38PlRIW
> Jw5vjZJZjdOivn3y/fccGq7ph3T0KTYPvCyc2nThVxGxaFB/mb4TLuZlGzXh2vYt
> PsIjW15V56zIhHK2oS9t32DAfd64fvz86BfpNwuizKLAqyqnO84fWysxuK8P5rnC
> 2S67YmP3DeC0IhVbDLNs1Gzpk4mMpQpbRIHiZR2gIVFswy4EKuwoDjDY0AgVb0zw
> 6+BovJNdm1BWiNbQgNnn6K2LC53Nsc95WQzLeticzvLGGyG7cz4pMyraIDoBfqg=
> =OKeU
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Functional tests for ironicclient

[Anton Arefiev]

Hi folks,

We have plans to write functional tests for ironicclient. And  the
following question arose :

In current realization, functional test environment uses ironicclient api
directly(client managers), this approach has one problem - it doesn't
include command-line interface code. So it would be better to use
tempest-lib for this. It makes call to ironic with Popen, and has code for
parsing results.

What do you think about this? Any suggestion will be appreciated.
-- 
Best regards,
Anton Arefiev
Mirantis, 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] [TripleO] Encapsulating logic and state in the client

[Dougal Matthews]

- Original Message -
> From: "Zane Bitter" 
> To: "OpenStack Development Mailing List" 
> Sent: Monday, 17 August, 2015 5:25:36 PM
> Subject: [openstack-dev] [TripleO] Encapsulating logic and state in the   
> client
> 
> It occurs to me that there has never been a detailed exposition of the
> purpose of the tripleo-common library here, and that this might be a
> good time to rectify that.
> 
> Basically, there are two things that it sucks to have in the client:
> 
> First, logic - that is, any code that is not related to the core client
> functionality of taking input from the user, making ReST API calls, and
> returning output to the user. This sucks because anyone needing to
> connect to a ReST API using a language other than Python has to
> reimplement the logic in their own language. It also creates potential
> versioning issues, because there's nothing to guarantee that the client
> code and anything it interacts with on the server are kept in sync.
> 
> Secondly, state. This sucks because the state is contained in a user's
> individual session, which not only causes all sorts of difficulties for
> anyone trying to implement a web UI but also means that you're at risk
> of losing some state if you e.g. accidentally Ctrl-C the CLI client.
> 
> Unfortunately, as undesirable as these are, they're sometimes necessary
> in the world we currently live in. The only long-term solution to this
> is to put all of the logic and state behind a ReST API where it can be
> accessed from any language, and where any state can be stored
> appropriately, possibly in a database. In principle that could be
> accomplished either by creating a tripleo-specific ReST API, or by
> finding native OpenStack undercloud APIs to do everything we need. My
> guess is that we'll find a use for the former before everything is ready
> for the latter, but that's a discussion for another day. We're not there
> yet, but there are things we can do to keep our options open to make
> that transition in the future, and this is where tripleo-common comes in.

+1, I've felt uneasy about the state of the CLI at the moment and I can
see real advantage in having a relatively think API that captures all of
this logic and workflow.

 
> I submit that anything that adds logic or state to the client should be
> implemented in the tripleo-common library instead of the client plugin.
> This offers a couple of advantages:
> 
> - It provides a defined boundary between code that is CLI-specific and
> code that is shared between the CLI and GUI, which could become the
> model for a future ReST API once it has stabilised and we're ready to
> take that step.
> - It allows for an orderly transition when that happens - we can have a
> deprecation period during which the tripleo-common library is imported
> into both the client and the (future, hypothetical) ReST API.

The other really big win is that it opens up the possibility of UIs and
CLIs written in other languages. A completely client side UI for example :)

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

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

Re: [openstack-dev] [tripleo] Upgrades, Releases & Branches

[Zane Bitter]

On 17/08/15 15:29, James Slagle wrote:

>
>I'd like propose we take a somewhat modified "release branch" approach,
>which combines many of the advantages of the stable-branch model, but
>allows for a somewhat more liberal approach to backports, where most things
>are considered valid backports provided they work with the currently
>released OpenStack services (e.g right now, a t-h-t release/kilo branch
>would have to maintain compatibility with a kilo Heat in the undercloud)

I like the idea, it seems reasonable to me.

I do think we should clarify if the rule is:

We*can*  backport anything to release/kilo that doesn't break
compatibility with kilo Heat.

Or:

We*must*  backport anything to release/kilo that doesn't break
compatibility with kilo Heat.


I think of it like this: there are theoretically 4 potential models for 
how to combine TripleO and OpenStack:


1) trunk TripleO deploys trunk OpenStack
2) trunk TripleO deploys stable OpenStack
3) stable TripleO deploys trunk OpenStack
4) stable TripleO deploys stable OpenStack

(You could double the size of this list by assuming a user was willing 
to use a different version of OpenStack in the undercloud than they're 
installing in the overcloud. However, I believe we are working on the 
assumption that they are not.)


To date, TripleO has supported only (1). This is a proposal to support 
(2). I'll hazard a guess that nobody cares about (3) right now. This is 
explicitly *not* a proposal to support (4) - i.e. it is not a stable/ 
branch (we'll continue to leave that job to downstream distros).


So we should think of this as a development branch that allows users to 
consume the latest TripleO features without breaking compatibility with 
the stable OpenStack packages. So, in RFC2119 terms, I believe the 
correct policy is we SHOULD backport anything to release/kilo (or 
whatever we call it) that doesn't break compatibility with kilo OpenStack.


cheers,
Zane.

__
OpenStack Development Mailing 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] should we allow overcommit for a single VM?

[Nikola Đipanov]

On 08/17/2015 08:22 PM, Chris Friesen wrote:
> 
> I tried bringing this up on the irc channel, but nobody took the bait.
> Hopefully this will generate some discussion.
> 
> I just filed bug 1485631.  Nikola suggested one way of handling it, but
> there are some complications that I thought I should highlight so we're
> all on the same page.
> 
> The basic question is, if a host has X CPUs in total for VMs, and a
> single instance wants X+1 vCPUs, should we allow it?  (Regardless of
> overcommit ratio.)  There is also an equivalent question for RAM.
> 
> Currently we have two different answers depending on whether numa
> topology is involved or not.  Should we change one of them to make it
> consistent with the other?  If so, a) which one should we change, and b)
> how would we do that given that it results in a user-visible behaviour
> change?  (Maybe a microversion, even though the actual API doesn't
> change, just whether the request passes the scheduler filter or not?)
> 

I would say that the "correct" behavior is what NUMA fitting logic does,
and that is to not allow instance to over-commit against itself, and we
should fix "normal" (non-NUMA) over-commit. Allowing the instance to
over-commit against itself does not make a lot of sense, however it is
not something that is likely to happen that often in real world usage -
I would imagine operators are unlikely to create flavors larger than
compute hosts.

I am not sure that this has anything to do with the API thought. This is
mostly a Nova internal implementation detail. Any nova deployment can
fail to boot an instance for any number of reasons, and this does not
affect the API response of the actual boot request.

Hope it helps,
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

Re: [openstack-dev] [TripleO] Encapsulating logic and state in the client

[Zane Bitter]

On 18/08/15 02:33, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2015-08-17 09:25:36 -0700:

It occurs to me that there has never been a detailed exposition of the
purpose of the tripleo-common library here, and that this might be a
good time to rectify that.

Basically, there are two things that it sucks to have in the client:

First, logic - that is, any code that is not related to the core client
functionality of taking input from the user, making ReST API calls, and
returning output to the user. This sucks because anyone needing to
connect to a ReST API using a language other than Python has to
reimplement the logic in their own language. It also creates potential
versioning issues, because there's nothing to guarantee that the client
code and anything it interacts with on the server are kept in sync.

Secondly, state. This sucks because the state is contained in a user's
individual session, which not only causes all sorts of difficulties for
anyone trying to implement a web UI but also means that you're at risk
of losing some state if you e.g. accidentally Ctrl-C the CLI client.

Unfortunately, as undesirable as these are, they're sometimes necessary
in the world we currently live in. The only long-term solution to this
is to put all of the logic and state behind a ReST API where it can be
accessed from any language, and where any state can be stored
appropriately, possibly in a database. In principle that could be
accomplished either by creating a tripleo-specific ReST API, or by
finding native OpenStack undercloud APIs to do everything we need. My
guess is that we'll find a use for the former before everything is ready
for the latter, but that's a discussion for another day. We're not there
yet, but there are things we can do to keep our options open to make
that transition in the future, and this is where tripleo-common comes in.

I submit that anything that adds logic or state to the client should be
implemented in the tripleo-common library instead of the client plugin.
This offers a couple of advantages:

- It provides a defined boundary between code that is CLI-specific and
code that is shared between the CLI and GUI, which could become the
model for a future ReST API once it has stabilised and we're ready to
take that step.
- It allows for an orderly transition when that happens - we can have a
deprecation period during which the tripleo-common library is imported
into both the client and the (future, hypothetical) ReST API.



I agree with most everything you've said above. But as someone mostly
disconnected from TripleO for the last 6 months, I have no idea what
you're talking about, specifically. Can you provide a specific example?


I can provide a specific example of what's in tripleo-common today: the 
workflow which drives package updates on the overcloud nodes. It works 
by kicking off a Heat stack-update and using hooks/breakpoints to 
shepherd it through the correct workflow - so this incorporates both 
logic and state.


In terms of what additional stuff might be added in the future, I was 
intentionally being somewhat generic in the hope that people would 
recognise their own situation in this description rather than try to 
predict what changes people might want to make in the future. I can 
imagine something like additional verification of input parameters (i.e. 
verifying them in combination, in a way that is application-specific and 
therefore cannot be done by Heat) would be an example we might hit.


cheers,
Zane.

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

Re: [openstack-dev] [Neutron][fwaas] APAC friendly meeting

[Furukawa, Yushiro]

Hi Sean,
CC: Hoang

Thank you for your kindness :-)

> I'm more of a night-owl than a morning person, so I can do 2300 UTC,  
> UTC, or
> 0100 UTC, so it is during the evening period of my local time, and the
> morning hours of APAC.

Hoang(hoangcx) and I(yushiro) would like to start 00:00 UTC.
(Hoang's timezone is VST and my timezone is JST.)

Best regards,
--
Yushiro FURUKAWA


__
OpenStack Development Mailing 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] Cross-Project meeting, Tue Aug 18th, 21:00 UTC

[Emilien Macchi]

Note for myself: do not take a day off before Cross-project meeting so I
can send the agenda on time :-)

Dear PTLs, cross-project liaisons and anyone else interested,

We'll have a cross-project meeting today at 21:00 UTC, with the
following agenda:

* Team announcements (horizontal, vertical, diagonal)
* How to generate .Z version increments on stable/liberty commits
* How to autogenerate release notes on stable/liberty commits
* Return request ID to caller
* Open discussion

If you're from an horizontal team (Release management, QA, Infra, Docs,
Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and
have something to communicate to the other teams, feel free to abuse the
relevant sections of that meeting and make sure it gets #info-ed by the
meetbot in the meeting summary.

See you there !

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
-- 
Emilien Macchi



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

[openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver

[Mathieu Rohon]

Adding the related subject :)

On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon 
wrote:

> Hi all,
>
> The current bgpvpn implementation is using the service type framework,
> with a service plugin and one or more service providers.
>
> After registering the bug [1], I wonder if we would rather use a service
> plugin per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which
> handles API calls, instead of having one service plugin which forwards API
> calls to a service driver depending on the provider chosen by the end
> user.
>
> I would like to better understand what would be the main drawbacks of such
> a move apart from the fact that a deployment would be tightly coupled to a
> bgpvpn plugin, and multiple implementations of the plugin couldn't coexist.
>
> Thanks,
>
> Mathieu
>
> [1]https://bugs.launchpad.net/bgpvpn/+bug/1485515
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack][oslo.service] Manage of openstack services by ProcessLauncher

[Davanum Srinivas]

I like #3 for windows. ("Do nothing.") :)

-- dims

On Tue, Aug 18, 2015 at 6:37 AM, Elena Ezhova  wrote:

> Thank you for bringing it up, Marian!
>
> On Mon, Aug 17, 2015 at 5:29 PM, mhorban  wrote:
>
>> Most of openstack services use ProcessLauncher(located in oslo.services)
>> to run services, fork new worker processes, reload configuration, etc.
>> Initialization of services in master process usually contains opening of
>> sockets, so that socket will be inherited in child processes. Then
>> master(parent) process spawns(with fork call) children. Communication
>> between master process and children is implemented with signals, for
>> example when master process wants to shutdown children it sends SIGTERM
>> signal to children, to reload children config master process sends SIGHUP
>> signal.
>>
>> I would like to discuss three things:
>>
>
> The first two points also apply to ServiceLauncher which is used to start
> services in case a number of workers is 0 or 1:
>
>
>> 1. Behaviour of reloading configuration in children processes.
>
>
> If a service receives SIGHUP it is restarted which implies calling stop,
> reset and then start.
>
> 2. Additional way to control of master process.
>>
>
>  ServiceLauncher handles the same signals as ProcessLauncher.
>
>
>> 3. Communication between master and children processes.
>
>
>> 1. Behaviour of reloading configuration in children processes.
>> Now we can reload processes by sending SIGHUP to master process. Master
>> process reloads its own configuration and sends SIGHUP signal to children.
>> When child process receives SIGHUP signal it loads config file, stops and
>> starts service. During stopping-starting service new config options usually
>> don't applied because there should be written a lot of code to manage
>> cofiguration changes. rpodolyaka expressed idea to shutdown children during
>> reloading configuration and respawn new workers. This approach frees us of
>> implementing a huge amount of service-related code for reloading
>> configuration of specific objects. Apache and NGINX uses the same reloading
>> approach: gracefully stop children and start new child instances.
>>
>
> From my point of view, this is a double-edged sword. On the one hand,
> respawning workers would indeed free us from writing reset logic for each
> service and save a lot of effort and time. On the other hand, the idea
> behind using SIGHUPs was to have an ability to make changing configuration
> as instantaneous and invisible to users as possible, ideally without
> stopping services. If we choose not to stop services at all (i.e. getting
> rid of calling stop and start on receiving SIGHUP) we'll be able to
> implement flexible configuration reloading (for example, changes to the RPC
> section of a config will invoke only re-initialization of RPC connections
> while db connections wouldn't be affected in any way).
> But this approach is really quite complex so I think we have to weight the
> pros and cons before making a decision.
>
>>
>> 2. Additional way to control of master process.
>> Right now we can control ProcessLauncher by sending signals to master
>> process. It is the only way to manage it. The problem is that such approach
>> is not platform independent. We already faced an issue: Windows doesn't
>> support SIGHUP signal, so part of functionality is inaccessible in Windows
>> :(. Usually process containers like ProcessLauncher could be managed by CLI
>> too. What do you think about creating listening interface for incoming
>> commands?
>>
>
> So, the main problem here is the lack of functionality on Windows. I see
> several ways how to solve this problem:
>
> 1. Send commands to a master process like Marian suggests. As a transport
> we can use sockets or pipes (need to research how are pipes implemented on
> Windows).
> 2. Accept one of the signals available on Windows as SIGHUP. There are
> quite a few of them [1], [2] but it'll still require some research on how
> Windows implements signals.
> 3. Do nothing. The fact that oslo.service currently doesn't support SIGHUP
> on Windows is documented and Windows users can simply restart a service if
> they need to reload config files.
>
>
>> 3. Communication between master and children processes.
>> Master process uses signals to control children. Since many signals are
>> not supported on some platforms I suggest to replace signal mechanism with
>> pipes. Each of children will listen to input commands on one side of pipe
>> and master process will write commands on the other side of pipe.
>>
>
> Pipes might be a good idea, but again we shouldn't remove handlers in
> children at least for those signals that are supported on all platforms
> (SIGINT and SIGTERM). There can be situations when we need to send a
> termination signal to some of the workers directly.
>
> Just my 2 cents :)
>
>
>
>>
>> Any idea?
>>
>> __
>> OpenStack Development Mailing List

Re: [openstack-dev] [openstack][oslo.service] Manage of openstack services by ProcessLauncher

[Elena Ezhova]

Thank you for bringing it up, Marian!

On Mon, Aug 17, 2015 at 5:29 PM, mhorban  wrote:

> Most of openstack services use ProcessLauncher(located in oslo.services)
> to run services, fork new worker processes, reload configuration, etc.
> Initialization of services in master process usually contains opening of
> sockets, so that socket will be inherited in child processes. Then
> master(parent) process spawns(with fork call) children. Communication
> between master process and children is implemented with signals, for
> example when master process wants to shutdown children it sends SIGTERM
> signal to children, to reload children config master process sends SIGHUP
> signal.
>
> I would like to discuss three things:
>

The first two points also apply to ServiceLauncher which is used to start
services in case a number of workers is 0 or 1:


> 1. Behaviour of reloading configuration in children processes.


If a service receives SIGHUP it is restarted which implies calling stop,
reset and then start.

2. Additional way to control of master process.
>

 ServiceLauncher handles the same signals as ProcessLauncher.


> 3. Communication between master and children processes.


> 1. Behaviour of reloading configuration in children processes.
> Now we can reload processes by sending SIGHUP to master process. Master
> process reloads its own configuration and sends SIGHUP signal to children.
> When child process receives SIGHUP signal it loads config file, stops and
> starts service. During stopping-starting service new config options usually
> don't applied because there should be written a lot of code to manage
> cofiguration changes. rpodolyaka expressed idea to shutdown children during
> reloading configuration and respawn new workers. This approach frees us of
> implementing a huge amount of service-related code for reloading
> configuration of specific objects. Apache and NGINX uses the same reloading
> approach: gracefully stop children and start new child instances.
>

>From my point of view, this is a double-edged sword. On the one hand,
respawning workers would indeed free us from writing reset logic for each
service and save a lot of effort and time. On the other hand, the idea
behind using SIGHUPs was to have an ability to make changing configuration
as instantaneous and invisible to users as possible, ideally without
stopping services. If we choose not to stop services at all (i.e. getting
rid of calling stop and start on receiving SIGHUP) we'll be able to
implement flexible configuration reloading (for example, changes to the RPC
section of a config will invoke only re-initialization of RPC connections
while db connections wouldn't be affected in any way).
But this approach is really quite complex so I think we have to weight the
pros and cons before making a decision.

>
> 2. Additional way to control of master process.
> Right now we can control ProcessLauncher by sending signals to master
> process. It is the only way to manage it. The problem is that such approach
> is not platform independent. We already faced an issue: Windows doesn't
> support SIGHUP signal, so part of functionality is inaccessible in Windows
> :(. Usually process containers like ProcessLauncher could be managed by CLI
> too. What do you think about creating listening interface for incoming
> commands?
>

So, the main problem here is the lack of functionality on Windows. I see
several ways how to solve this problem:

1. Send commands to a master process like Marian suggests. As a transport
we can use sockets or pipes (need to research how are pipes implemented on
Windows).
2. Accept one of the signals available on Windows as SIGHUP. There are
quite a few of them [1], [2] but it'll still require some research on how
Windows implements signals.
3. Do nothing. The fact that oslo.service currently doesn't support SIGHUP
on Windows is documented and Windows users can simply restart a service if
they need to reload config files.


> 3. Communication between master and children processes.
> Master process uses signals to control children. Since many signals are
> not supported on some platforms I suggest to replace signal mechanism with
> pipes. Each of children will listen to input commands on one side of pipe
> and master process will write commands on the other side of pipe.
>

Pipes might be a good idea, but again we shouldn't remove handlers in
children at least for those signals that are supported on all platforms
(SIGINT and SIGTERM). There can be situations when we need to send a
termination signal to some of the workers directly.

Just my 2 cents :)



>
> Any idea?
>
> __
> OpenStack Development Mailing 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://docs.python.org/2/library/signal.html#signal.signal
[2] https:/

Re: [openstack-dev] [Neutron] revert default review branch to master

[Mooney, Sean K]

Since Doug Wiegley's change has merged 
https://review.openstack.org/#/c/213843/
Ill Abandon mine and close/update the bug accordingly.

I was a little confused when I rebased and ended up pushing a review to 
feature/qos instead of master.

Regards
sean

-Original Message-
From: Miguel Angel Ajo [mailto:mangel...@redhat.com] 
Sent: Tuesday, August 18, 2015 9:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] revert default review branch to master

Thanks for handling this so quickly Sean!

Kyle Mestery wrote:
> On Mon, Aug 17, 2015 at 5:58 PM, Jeremy Stanley  wrote:
>
>> On 2015-08-17 22:39:56 + (+), Mooney, Sean K wrote:
>> [...]
>>> Assuming this was not intentional I have opened a bug and submitted 
>>> a patch to revert this change.
>> [...]
>>
>> Fix https://review.openstack.org/213843 is already winding its way 
>> through the sausage factory.
>>
>
> Yes, this was missed during the merge back of feature/qos, of which I 
> approved the merge commit. Thanks to Doug for jumping on this with 
> 213843 here, which is almost finished having it's casing added.
>
> --
>> Jeremy Stanley
>>
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

__
OpenStack Development Mailing 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] [third-party-ci]Tests randomly failing because of lvm

[Eduard Matei]

Hi,

Might be because volume backing size of 32G results in 8191 PE instead of
8192, so last volume create attempt sees only 1023 free extents.

Will retry with 32768M

Eduard
__
OpenStack Development Mailing 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] revert default review branch to master

[Miguel Angel Ajo]

Thanks for handling this so quickly Sean!

Kyle Mestery wrote:

On Mon, Aug 17, 2015 at 5:58 PM, Jeremy Stanley  wrote:


On 2015-08-17 22:39:56 + (+), Mooney, Sean K wrote:
[...]

Assuming this was not intentional I have opened a bug and
submitted a patch to revert this change.

[...]

Fix https://review.openstack.org/213843 is already winding its way
through the sausage factory.



Yes, this was missed during the merge back of feature/qos, of which I
approved the merge commit. Thanks to Doug for jumping on this with 213843
here, which is almost finished having it's casing added.

--

Jeremy Stanley

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



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



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

Re: [openstack-dev] [tripleo] Upgrades, Releases & Branches

[Thierry Carrez]

Steven Hardy wrote:
> The obvious answer is a stable branch for certain TripleO components, and
> in particular for t-h-t, but this has disadvantages if we take the
> OpenStack wide "no feature backports" approach - for example "upgrade
> support to liberty" could be considered a feature, and many other TripleO
> "features" are really more about making features of the deployed OpenStack
> services consumable.
> 
> I'd like propose we take a somewhat modified "release branch" approach,
> which combines many of the advantages of the stable-branch model, but
> allows for a somewhat more liberal approach to backports, where most things
> are considered valid backports provided they work with the currently
> released OpenStack services (e.g right now, a t-h-t release/kilo branch
> would have to maintain compatibility with a kilo Heat in the undercloud)

I think that makes sense.

The critical point being they should *not* be named stable/$SERIES
(which kind of indicates that you follow the stable branch policy), but
something else. release/$SERIES is slightly tainted (used to be the name
of the pre-release branches we created during RCs before release) but I
don't really have better suggestions (deploy/$SERIES ? support/$SERIES ?).

I agree with James that you'll need to clearly describe such branch
policy (everything should be backported ? everything can be backported ?
Only specific things can be backported ?) so that everyone is on the
same page.

Cheers,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [neutron][bgpvpn]

[Mathieu Rohon]

Hi all,

The current bgpvpn implementation is using the service type framework, with
a service plugin and one or more service providers.

After registering the bug [1], I wonder if we would rather use a service
plugin per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which
handles API calls, instead of having one service plugin which forwards API
calls to a service driver depending on the provider chosen by the end user.

I would like to better understand what would be the main drawbacks of such
a move apart from the fact that a deployment would be tightly coupled to a
bgpvpn plugin, and multiple implementations of the plugin couldn't coexist.

Thanks,

Mathieu

[1]https://bugs.launchpad.net/bgpvpn/+bug/1485515
__
OpenStack Development Mailing 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] [stable] [infra] How to auto-generate stable release notes

[Thierry Carrez]

Dave Walker wrote:
> On 17 August 2015 at 15:59, Jeremy Stanley  wrote:
>> On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
>> [...]
>>> OSSA: 
>>> For commits that correspond to vulnerability fixes.
>> [...]
>>
>> I don't think that's going to be feasible. Consider the sequence
>> with a public security vulnerability... often the OSSA number isn't
>> assigned until after one or more backports have been approved. With
>> some careful controls introduced into the VMT process we may be able
>> to make sure most of these get updated commit messages before they
>> merge, but would still need a plan to solve for the times when
>> backported security fixes slip in without an OSSA header in the
>> commit message.

That's actually another case where we need to be able to fix up release
notes after the fact. So my question still stands:

> We also might need a mechanism to add to release notes when we realize
> after the fact that a specific commit in past history warrants a
> highlight. Would some kind of no-change commit do the trick ?

Dave suggested:

> Maybe this is a perfect use-case for git-notes?  This means the commit
> itself isn't touched and the non-scale git-tag space isn't wasted?

It definitely seems to be the perfect match: adding notes to commits
lets us document release notes both during and after backports, without
altering commit messages.

The trick is that like git tags, git notes do not appear to be
code-reviewable using Gerrit, they are directly pushed by people with
Push Refs rights (or by Gerrit itself on merge to store approval
details). So ideally we want to generate them from properly
code-reviewed data.

We could have a Gerrit plugin (inspired from the reviewnotes plugin)
that takes specific headers from commit messages and populate a
"releasenote" git note accordingly.

For after-the-fact git notes (say, to add an OSSA reference to an
already-merged commit), we could have a section in the
openstack/releases proposed change that describes additional
"releasenote" git notes to push to old commits when the change is accepted.

Something like:

additional-notes:
  cc6c50ee23f336d08e4fe833070943c0025a205d:
OSSA: 2015-022
  fcfbf8eb0e0d42ff54bd014bc9e43f5f48bd7a68:
Release-note: >
  Fixing bug 1237534 actually results in a 10x performance
  improvement listing networks connected to an instance

That way all note content is properly reviewed before they make it to
the git notes.

Then pbr would just parse git notes instead of commit messages to
generate releasenotes files in the code tarballs.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

[Thomas Bechtold]

On Mon, 2015-08-17 at 13:36 +, Jeremy Stanley wrote:
> On 2015-08-17 15:25:07 +0200 (+0200), Thierry Carrez wrote:
> [...]
> > I see Doug, Robert, Clark and myself as necessary to the
> > discussion
> [...]
> 
> It would also be great to get some of the operators and/or package
> maintainers involved since they were the ones arguing against the
> original and much simpler proposal (no longer making stable branch
> point releases at all). 

SUSE packaging is tracking every commit from the stable branches and
generates packages from that. It's fully automated. So it doesn't
matter for SUSE if we create releases or not.


Cheers,

Tom

__
OpenStack Development Mailing 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][puppet] The state of collaboration: 9 weeks

[Dmitry Borodaenko]

Two weeks ago, I flagged the patch sets to commits ratio as the biggest
problem that Fuel contributors to Puppet OpenStack should address, and
over the past two weeks the situation has improved dramatically. In
first and second week of August, 19 of our commits were merged in
upstream, bringing our patch sets per commit ratio from 19 down to 5.6
(while average for Puppet OpenStack during that period was 6.5). With
the share of patch sets pushed by Fuel developers remaining at roughly
the same level (15.9% vs 17.4%), I think it's safe to call this problem
solved. Simply awesome!

Comparing last 30 days contribution stats vs same numbers two weeks ago:

Bogdan Dobrelia (#3 reviewer!): 67.2% -> 66.3% (disagreements 4.9% -> 3.6%)
Denis Egorenko: 97% -> 87.5% (disagreements 12.1% -> 13.9%)
Vasyl Saienko: 100% -> 96.4% (disagreements 16.7% -> 10.7%)
Ivan Berezovskiy: 100% -> 92.3% (disagreements 0% -> 3.8%)
Sergey Kolekonov: 91.7% -> 95.7% (disagreements 8.3% -> 13%)
Max Yatsenko: n/a -> 100% (disagreements n/a -> 17.4%)
Alex Schultz: 80% -> 80% (disagreements 20% -> 26.7%)
Bartlomiej Piotrowski: n/a -> 100% (disagreements n/a -> 12.5%)
Sergii Golovatiuk: 100% -> 100% (disagreements 33.3% -> 0%)

Bogdan continues to set the example and improve his numbers, which is
not surprising considering that he's also the top reviewer in
fuel-library. I think puppet-nova and puppet-neutron teams should
seriously consider nominating him for core, he already tops reviewers
lists for these modules.

Denis, Vasyl, and Ivan are not there yet, but they all have noticeably
increased both number and quality of their reviews, keep it up guys!

Numbers for other top reviewers are uneven and small enough for noise to
overtake meaningful data, all I can recommend here is to watch your
disagreements and learn from them. A ratio above 10% can mean one of
three things: 1) you're not doing enough reviews so even a handful of
disagreements sticks out -- do more reviews and this will improve on its
own; 2) you're missing problems with the code that other reviewers find
unacceptable -- try to be more attentive and watch for the things that
you've been missing; 3) you disagree with majority on how some things
should be done -- discuss your differences on IRC or ML and figure out a
consensus.

Moving on to other numbers, weekly IRC meetings participation remains
good:

Aug-4: 4 of 15 participants, 22 of 162 lines
Aug-11: 6 of 16 participants, 62 of 192 lines

Unfortunately it's not all roses and unicorns, last week I flagged a
stuck review that I think has been mishandled by Puppet OpenStack team
[0][1], and it still remains in the same state.

[0] https://review.openstack.org/198695
[1] 
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-11-15.00.log.html#l-140

On July 8, patch set 2 has passed CI. It received 2 +1 votes from other
Fuel developers on July 10 and 29, but remained ignored by upstream
reviewers until August 10, more than a month after the current patch set
was posted. Then, a Swift core reviewer left a -1 disagreeing with the
intent of the patch, and even though patch author posted a rebuttal a
day later, the patch remains stuck and untouched for yet another week.

It's a one-off case that does not outweigh the positive trends I've
outlined above, but even one stuck patch that fixes a critical bug is
enough to justify a fork.

Speaking of forks, we managed to un-fork 9 upstream modules [2] with
puppet-librarian-simple before Fuel 7.0 soft code freeze has kicked in.

[2] https://github.com/stackforge/fuel-library/blob/master/deployment/Puppetfile

That's 9 times more than my conservative estimate of converting at least
1 module to librarian in 7.0, but these were the easiest and least
deviated from upstream. We've still got 50 more modules to convert in
Fuel 8.0, many will require commits to be merged in upstream before they
can be completely un-forked. Having such commits wait for a month at a
time only to be summarily rejected puts this effort at risk, lets figure
out what went wrong this time and come up with a way to prevent this
from happening again.

Thanks,

--
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] [cinder] Midcycle Sprint Summary

[Gorka Eguileor]

On Mon, Aug 17, 2015 at 08:53:29AM -0700, Mike Perez wrote:
> A *summary* of the Cinder midcycle sprint, in attempt to keep your attention.
> Full meeting notes available [1].
> 
> [ ... ]
> 
> -- Mike Perez

Thank you very much for the summary.

Cheers,
Gorka.

__
OpenStack Development Mailing 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] [third-party-ci]Tests randomly failing because of lvm

[Eduard Matei]

Hi,

Further investigation shows there might be a relation between a test
failing because it can't upload an image (most likely because there's not
enough space left) and another test failing because lvm doesn't have enough
extents - at the same time (due to tests running on two workers). So if
these tests run at the same time, they will both fail.

I increased VOLUME_BACKING_FILE_SIZE to 32G but still same error.

Any idea how to fix this?
Can i increase the number of "extents"? (how?) Or can i increase the disk
size of the image? (again how?)

Thanks,

Eduard
__
OpenStack Development Mailing 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] Upgrades, Releases & Branches

[marios]

On 17/08/15 22:29, James Slagle wrote:
> On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy  wrote:
>> Hi all,
>>
>> Recently I had some discussion with folks around the future strategy for
>> TripleO wrt upgrades, releases and branches, specifically:
>>
>> - How do we support a "stable" TripleO release/branch that enables folks to
>>   easily deploy the current stable release of OpenStack
>> - Related to the above, how do we allow development of TripleO components
>>   (and in particular t-h-t) to proceed without imposing undue constraints
>>   on what new features may be used (e.g new-for-liberty Heat features which
>>   aren't present in the current released OpenStack version)
>> - We're aiming to provide upgrade support, thus from and to which versions?
>>
>> I know historically TripleO has taken something of a developer and/or
>> continuous deployment model for granted, but I'd like to propose that we
>> revisit that discusion, such that we move towards something that's more
>> consumable by users/operators that are consuming the OpenStack coordinated
>> releases.
>>
>> The obvious answer is a stable branch for certain TripleO components, and
>> in particular for t-h-t, but this has disadvantages if we take the
>> OpenStack wide "no feature backports" approach - for example "upgrade
>> support to liberty" could be considered a feature, and many other TripleO
>> "features" are really more about making features of the deployed OpenStack
>> services consumable.
>>
>> I'd like propose we take a somewhat modified "release branch" approach,
>> which combines many of the advantages of the stable-branch model, but
>> allows for a somewhat more liberal approach to backports, where most things
>> are considered valid backports provided they work with the currently
>> released OpenStack services (e.g right now, a t-h-t release/kilo branch
>> would have to maintain compatibility with a kilo Heat in the undercloud)
> 
> I like the idea, it seems reasonable to me.
> 
> I do think we should clarify if the rule is:
> 
> We *can* backport anything to release/kilo that doesn't break
> compatibility with kilo Heat.
> 
> Or:
> 
> We *must* backport anything to release/kilo that doesn't break
> compatibility with kilo Heat.
> 
> If it's the former, I think we'd get into a lot of subjective
> discussions around if we want certain things backported or not.
> Essentially it's the same discussion that happens for stable/*, except
> we consider features as well. This could become quite difficult to
> manage, and lead to a lot of reviewer opinionated inconsistency into
> what actually ends up getting backported.
> 
> For instance, there could be a very large and disruptive feature that
> doesn't break compatibility at all, but some users may not want to see
> it in release/kilo. Or, something like the recent proposed patch to
> rename a bunch of templates by dropping the "-puppet". That doesn't
> break compatibility with a kilo Heat at all, however it could break
> compatibility with someone's scripts or external tooling, and might be
> a considered an "API" incompatible change. The consuming downstreams
> (RDO) may not want to consume such a change. I know we don't have any
> official published "API" for tripleo-heat-templates, I'm just trying
> to think about how people consume the templates, and what they might
> find surprising if they were to be using release/kilo.
> 
> The question kind of comes down to if release/kilo is meant to imply
> any "stability". Or, if it's just meant to imply that you will always
> be able to deploy OpenStack Kilo with release/kilo of
> tripleo-heat-templates.

yes, my understanding too is that the 'compatibility' guarantee would be
a big part of this idea - one problem we consistently hit in the last
period was not being able to use (latest master of) component x with
(latest master of) tripleo-heat-templates (for example). Using
release/latest across all the projects would mean you'd use the latest
versions of things that have actually been ci'd and seen to work with
each other to give you an OpenStack latest deployment.

> 
> I think it's important to decide this up front so we can set the
> expectation. I'm leaning towards the latter ("must backport") myself,
> but then I wonder if the release branch would really solve the
> downstream use.

+1 on the must (sorry gfidente, wanted to reply on yours but wanted to
quote slagle in response)

Your point about does it really solve the downstream use still stands in
the can case though (even more so, e.g. one downstream influencing which
patches "can" go to release branch).

> 
>>
>> I know in the past stable branches have been discounted due to capacity
>> concerns, but the reality atm is such branches are likely to be maintained
>> downstream due to release-orientated efforts based on TripleO (e.g
>> rdo-manager) anyway, so it could be better for the TripleO community if we
>> maintained such branches upstream, where they can be consumed more directl

Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

[Rick Chen]

Hi Adhishek:

It is auto invoked.

 

From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] 
Sent: Tuesday, August 18, 2015 2:19 PM
To: Rick Chen 
Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

 

Also the "prophetstor_ci.htaccess", is it invoked automatically or you are 
doing something to invoke it ?

 

On Tue, Aug 18, 2015 at 11:46 AM, Abhishek Shrivastava mailto:abhis...@cloudbyte.com> > wrote:

No just want to know that only, if it is doing the job then its totally great.

 

On Tue, Aug 18, 2015 at 11:39 AM, Rick Chen mailto:rick.c...@prophetstor.com> > wrote:

HI Adhishek:

Yes, any problem? What do I do wrong?

 

From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com 
 ] 
Sent: Tuesday, August 18, 2015 1:57 PM


To: Rick Chen mailto:rick.c...@prophetstor.com> >
Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

 

So you have created one .htaccess file in your log folder, am I right?

 

On Tue, Aug 18, 2015 at 11:19 AM, Rick Chen mailto:rick.c...@prophetstor.com> > wrote:

HI Adhishek:

I add “AllowOverride all” option and point to the OpenStack CI log 
folder in the apache configuration.



Options Indexes FollowSymLinks

AllowOverride All

Require all granted



and set the .htaccess file in the /var/log/prophetstor_ci.

.htaccess contents as below:

Options Indexes FollowSymLinks

Order allow,deny

Allow from all

RewriteEngine On

RewriteCond   %{HTTP:Accept-Encoding} gzip

RewriteCond   %{LA-U:REQUEST_FILENAME}.gz -f

RewriteRule   ^(.+)$ $1.gz [L]



  ForceType text/html

  AddDefaultCharset UTF-8

  AddEncoding x-gzip gz



reference: http://httpd.apache.org/docs/2.2/howto/htaccess.html

 

 

From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com 
 ] 
Sent: Tuesday, August 18, 2015 1:05 PM
To: Rick Chen mailto:rick.c...@prophetstor.com> >
Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

 

Hi Rick,

 

I know we had to put the following for making logs browsable, but where exactly 
to put it, I mean in which file can you specify it clearly.

 

On Tue, Aug 18, 2015 at 9:28 AM, Rick Chen mailto:rick.c...@prophetstor.com> > wrote:

HI Adhishek:

 

One more information, how are you catching the logs and making it browsable?

Do you mean item[6]? I just follow OpenStack Third-part CI document. 
You can reference 
http://docs.openstack.org/infra/system-config/third_party.html#faq-frequently-asked-questions.
 Add this configuration in our web server.

 

 

On Tue, Aug 18, 2015 at 7:10 AM, Rick Chen mailto:rick.c...@prophetstor.com> > wrote:

HI Abhishek:

For you information in the below. 

 

HI Mike:

What I have missed it?

 

On Mon, Aug 17, 2015 at 8:52 PM, Rick Chen mailto:rick.c...@prophetstor.com> > wrote:

HI Mike:
I completed to refine our CI configuration to follow Ramy's
comments. Does any missed or other attention I need respect?

[1] Add "export DEVSTACK_GATE_TEMPEST_REGEX=volume" to verify all
cinder volume testing.
[2] Add each service configuration in the log.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds 

 
vm-tempest-cinder-ci/5100/logs/etc/
[3] Add email alert when the devstack build failed to instead of you
notify to me.

 

​Can you please tell me that how ​

 

​you have done the [3].​

Use Jenkins email E-mail Notification.

Manage Jenkins >> Configure System >> E-mail Notification

Add SMTP server and Default user e-mail suffix. Use advanced 
button to verify email seting.

Add Email notification in you job.

CI job >> “Add post-build action” >> “Email Notification” >> 
add Recipients.

Reference link:  

 
https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch08s02.html

 

 

[4] Integrate VMware snapshot revert feature in the Jenkins master
to clean CI slave machine OS environment that avoid the devstack building
failed due to previous devstack garbage configuration.

 

​Also, the process of CI slave snapshot revert mentioned in [4].

​Add Jenkins plugin agent: vSphere Cloud Plugin

Configure vSphere Cloud in Jenkins master.

Manage Jenkins >> Configure System >> vSphere Cloud

Add vSphere hose, user name, password.

Configure vSphere Slave.

Add slave node and select “Slave virtual computer running under 
vSphere Cloud”

Manage Jenkins >> Manage Nodes >> New node >> select “Slave virtual 
computer running under vSphere Cloud”

Add your vSphere information in this configura