[openstack-dev] [Fuel] Changing APIs and API versioning

[Roman Prykhodchenko]

Hi folks,

I’d like to touch the aspect of Fuel development process that seems to be as 
wrong as possible. That aspect is how we change the API.

The issue is that in Fuel anyone can change API at any point of time without 
even warning the rest of the same component’s team. Relying on this kind of API 
is basically impossible. We constantly have problems when even components of 
Fuel stop working due to unexpected changes in the API. Thinking about another 
software that must be integrated with Fuel is hardly possible with the current 
approach.

As for a grown-up project there is a strong need for Fuel in general and for 
Nailgun in particular to work on a policy for making changes to their APIs. 
Living in OpenStack ecosystem we must at least take a look how it’s done in its 
components and try to do something similar. After working with Nova, Keystone, 
Ironic and other components I would propose to start with the following: let’s 
not make any changes to the API. Instead, let’s create a new version of 
Nailgun’s API that will appear in Fuel 8.0 and make all the changes there. That 
is the thing that will instantaneously make lives of other components much 
easier, if we make it now.

After doing the essential part let’s think about how we are going to live with 
that in the future. There are several APIs in Fuel, the rest of the email is 
only touching Nailgun’s REST API. I can see the things somehow like the 
following:

 - Introduce API documentation by embedding Swagger and Swagger UI.
   The current approach when we leave API docs for documentation team is not 
effective. Swagger generates the documentation and resolves this issue.
 - After releasing a version of Fuel, it’s API is called stable and frozen for 
any changes, unless they allign API to the documentation or documentation to 
the API.
 - All changes to a stable APIs must be backported to the stable version of 
Fuel that introduced the corresponding API.
 - In order to guarantee that a stable API is not changed, Jenkins jobs should 
make automatic checks for every new patch set

Details about all the above mentioned proposals can be discussed in separate 
threads so this one will stay uncluttered. I'd like to also summon those 
OpenStack folks, who tried to resolve the same issue and ask them about any 
common solutions in the ecosystem.


- romcheg






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

Re: [openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Markus Zoeller]

Lingxian Kong  wrote on 10/21/2015 06:44:27 AM:

> From: Lingxian Kong 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/21/2015 06:44 AM
> Subject: Re: [openstack-dev] [nova-compute][nova][libvirt] Extending 
> Nova-Compute for image prefetching
> 
> Hi, Alberto,
> 
> I'm really interested in your proposal, have you already submitted
> your spec? or is there any topic for you to have a discussion with
> Nova team in design summit?
> 
> I wonder what if the nova compute host use shared storage backend,
> like NFS or Ceph?
> 
> I have another suggestion, we can consider adding this capability in
> nova manage CLI, since it's just may be used by operator or
> administrator(at least for create/update/delete command), right?

Could you maybe add a short explanation what the use case is? IOW,
when and why do I (in whatever role) prefetch images? 

Regards, Markus Zoeller (markus_z)



__
OpenStack Development Mailing 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] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks

[Behzad Dastur]

Thanks Yair,
I will dig into this more. I did try the "network" context, but same error.

regards
Behzad

On Tue, Oct 20, 2015 at 12:53 PM, Yair Fried  wrote:

>
>
> On Tue, Oct 20, 2015 at 8:39 PM, Behzad Dastur 
> wrote:
>
>> Hi Yair,
>> The rally version I am using is 0.1.2
>>
>> > rally --version
>> 0.1.2
>>
>> Also the task file is as shown below. Do you have an example of the
>> "network" context to skip creation on the interface on the xternal network?
>>
> have you seen the plugin reference?
> https://rally.readthedocs.org/en/latest/plugin/plugin_reference.html
> Looks like there's also existing_network [context] but I'm unfamiliar with
> it.
>
>> vagrant@rally:~/rally$ more /vagrant/boot.json
>>
>> {% set flavor_name = flavor_name or "m1.tiny" %}
>>
>> {
>>
>> "NovaServers.boot_server": [
>>
>> {
>>
>> "args": {
>>
>> "flavor": {
>>
>> "name": "{{flavor_name}}"
>>
>> },
>>
> "auto_assign_nic": true,
>
>> "image": {
>>
>> "name": "cirros-0.3.1-x86_64"
>>
>> },
>>
>> "use_floatingip": false
>>
> I think this should be true (or maybe even removed)
>
>> },
>>
>> "runner": {
>>
>> "type": "constant",
>>
>> "times": 10,
>>
>> "concurrency": 2
>>
>> },
>>
>> "context": {
>>
> "network": {"networks_per_tenant": 1},
>
>> "users": {
>>
>> "tenants": 3,
>>
>> "users_per_tenant": 2
>>
>> }
>>
>> }
>>
>> }
>>
>> ]
>>
>> }
>>
>> regards,
>> Behzad
>>
>> Date: Tue, 20 Oct 2015 15:04:46 +0300
>> From: Yair Fried 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [rally] Rally boot tests fails with Error
>> Forbidden: It is not allowed to create an interface on external
>> networks
>> Message-ID:
>> 

[openstack-dev] [puppet] Incompatible default parameters

[Martin Mágr]

Greetings,

  I'd like to discuss bug 1506061 ([1]). The main problem I'm trying to 
solve here is that using default parameters of classes cinder::api and 
nova::keystone::auth migration won't work, because Cinder will search 
for endpoint with different name ('Compute service' instead of 'nova'). 
I've submitted fix for that in first patchset of [2], but it was denied 
as backward incompatible change, which I agree with, and instead I just 
added warnings about rename in next cycle [3].


  So the question is if we should start following endpoint naming 
according to Keystone's default catalog or just change default value of 
$nova_catalog_.*info parameters in cinder::api to match endpoint created 
by nova::keystone::auth? I don't mind going one way or another, but I do 
think that default parameters has to create fully functional environment.


Thanks in advance for answers,
Martin

[1] https://bugs.launchpad.net/puppet-nova/+bug/1506061
[2] https://review.openstack.org/#/c/222120/1
[3] 
https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1506061,n,z

[4] https://review.openstack.org/#/c/219284/2/manifests/api.pp

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

Re: [openstack-dev] [Ceilometer] Meeting cancelled for this week

[gord chung]

thanks Ildiko

it's also safe to assume the meeting will be cancelled for October 29 
and November 5. please use the mailing list (it's actually preferred) 
for any discussion items.


On 21/10/2015 8:22 AM, Ildikó Váncsa wrote:

Hi All,

I would like to inform you that we cancel the Ceilometer meeting for this week 
in favor of Summit travels and preparation.

We finished to organize our sessions for next week, you can find the schedule 
here: https://mitakadesignsummit.sched.org/overview/type/ceilometer
The etherpads for the sessions are available here: 
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Ceilometer

Best Regards,
Ildikó

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


--
gord


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

Re: [openstack-dev] [neutron][sriov] SRIOV-VM could not work well with normal VM

[Moshe Levi]

> -Original Message-
> From: yujie [mailto:judy_yu...@126.com]
> Sent: Tuesday, October 20, 2015 5:34 AM
> To: Moshe Levi 
> Cc: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [neutron][sriov] SRIOV-VM could not work well
> with normal VM
> 
> Hi Moshe Levi,
> Sorry for replying to this message after so long time. The testing
> environment was unavailable before.
> I use Intel cards, but could only tested base kilo and vlan. Could it 
> work?
I am not failure with Intel cards, but as far as I know it should work with 
flat network not sure it will work with vlan 
> 
> 在 2015/9/22 13:24, Moshe Levi 写道:
> > Hi Yujie,
> >
> > There is a patch https://review.openstack.org/#/c/198736/ which I
> > wrote to add the mac of the normal instance to the SR-IOV embedded
> switch so that the packet will go to the PF instead of going to the wire.
> > This is done by using bridge tool with the command "bridge fdb add 
> dev "
> >
> > I was able to test it on Mellanox ConnectX3  card with both  vlan and flat
> network and it worked fine.
> > I wasn't able to test it on any of the Intel cards, but I was told the it 
> > only
> working on flat network, in vlan network the Intel card is dropping the tagged
> packets and they are not go up to the VF.
> >
> > What NIC are you using? Can you try using "bridge fdb add  dev
> > " where  is the mac of the normal vm and  is
> the PF and see if  that resolve the issue.
> > Also can you check it with  flat and vlan networks.
> >
> >
> > -Original Message-
> > From: yujie [mailto:judy_yu...@126.com]
> > Sent: Tuesday, September 22, 2015 6:28 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [neutron][sriov] SRIOV-VM could not work well
> > with normal VM
> >
> > Hi all,
> > I am using neutron kilo without dvr to create sriov instance VM-A,it works
> well and could connect to its gateway fine.
> > But when I let the normal instance VM-B which in the same compute-node
> with VM-A ping its gateway, it failed. I capture the packet on the network-
> node, find the gateway already reply the ARP-reply message to VM-B. But
> compute-node which VM-B lives could not send the package to VM-B.
> > If delete VM-A and set : echo 0 >
> > /sys/class/enp5s0f0/device/sriov_numvfs, the problem solved.
> >
> > Is it a same question with the bug: SR-IOV port doesn't reach OVS port on
> same compute node ?
> > https://bugs.launchpad.net/neutron/+bug/1492228
> > Any suggestions will be grateful.
> >
> > Thanks,
> > Yujie
> >
> >
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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

[openstack-dev] [Neutron][Kuryr] IRC Meeting - Canceled for next week (10/26)

[Gal Sagie]

Hello Everyone,

Just wanted to share with anyone that wasn't in the meeting this week, that
we decided
to cancel the IRC meeting on the 10/26.

See you all in the summit.

Gal.
__
OpenStack Development Mailing 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] Incompatible default parameters

[Mathieu Gagné]

This change [1] introduced the nova_catalog_info and
nova_catalog_admin_info parameters.

Martin Mágr also mentioned that default values were wrong but the change
got merged anyway.

I agree that those default values should be changed to "nova" like
initially suggested as the 2nd field is the service_name, not
service_description. See default values in Cinder. [2]

This also means default values won't work for anyone, even people with
new or existing installations.

The default values in our manifests should be changed. There is no
backward compatibility breakage since it never worked in the first place.

Furthermore, existing installations NEED to update the default values
through Hiera or other means to make it work. Those people won't see the
change in default values.

I also think those parameters (and os_privileged_user_*) are in the
wrong manifest. Those values are also used by the cinder-volume service
to perform hypervisor assisted snapshots. They need to be moved.

[1] https://review.openstack.org/#/c/219284/2
[2]
http://docs.openstack.org/kilo/config-reference/content/section_cinder.conf.html

Mathieu

On 2015-10-21 9:39 AM, Clayton O'Neill wrote:
> I think the only people that would be affected by the puppet-openstack
> module default not matching the keystone default are people that are
> trying to retrofit puppet into an already running environment.  Those
> people already have a ton of work laid out in front of them, so I’m ok
> with making it very slightly more difficult for them (if those people
> even exist).
> 
> However, for existing users of the modules, this is potentially a big
> pain, since we already have existing catalogs with the old (wrong) name.
> 
> For new users of the module, this might be slightly annoying, but again,
> they can override it.
> 
> Personally I’d prefer to leave it as is, instead of requiring all
> existing users of the modules to change.
> 
> On Wed, Oct 21, 2015 at 9:31 AM, Martin Mágr  > wrote:
> 
> Greetings,
> 
>   I'd like to discuss bug 1506061 ([1]). The main problem I'm trying
> to solve here is that using default parameters of classes
> cinder::api and nova::keystone::auth migration won't work, because
> Cinder will search for endpoint with different name ('Compute
> service' instead of 'nova'). I've submitted fix for that in first
> patchset of [2], but it was denied as backward incompatible change,
> which I agree with, and instead I just added warnings about rename
> in next cycle [3].
> 
>   So the question is if we should start following endpoint naming
> according to Keystone's default catalog or just change default value
> of $nova_catalog_.*info parameters in cinder::api to match endpoint
> created by nova::keystone::auth? I don't mind going one way or
> another, but I do think that default parameters has to create fully
> functional environment.
> 
> Thanks in advance for answers,
> Martin
> 
> [1] https://bugs.launchpad.net/puppet-nova/+bug/1506061
> [2] https://review.openstack.org/#/c/222120/1
> [3]
> 
> https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1506061,n,z
> [4] https://review.openstack.org/#/c/219284/2/manifests/api.pp
> 
> __
> OpenStack Development Mailing 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] [Monasca] Congress + Monasca Meeting

[Fabio Giannetti (fgiannet)]

Guys,
  We have half slot on Wed 3:40 with the Congress folks:

https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Congress

These are the topics I proposed:

  1.  how to integrate Monasca with Congress so then Monasca can provide 
metrics, logs and event data for policy evaluation/enforcement
  2.  How to leverage Monasca alarming to automatically notify about statuses 
that may imply policy breach
  3.  How to automatically (if possible) convert policies (or subparts) into 
Monasca alarms.

Probably we will manage to get an intent to work on these topics since we have 
20min, but it is a start :-)
Thanks,
Fabio

From: Fabio Giannetti >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, October 14, 2015 at 4:07 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Monasca] Monasca Meeting @ Tokyo Summit

Hi Oğuz,
   YES this is open to everybody.
Thanks,
Fabio

[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_06.png?ct=1430182397611]

Fabio Giannetti
Cloud Innovation Architect
Cisco Services
fgian...@cisco.com
Phone: +1 408 527 1134
Mobile: +1 408 854 0020


Cisco Systems, Inc.
285 W. Tasman Drive
San Jose
California
95134
United States
Cisco.com





[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

Please click 
here for 
Company Registration Information.



From: Oğuz Yarımtepe >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, October 13, 2015 at 11:22 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Monasca] Monasca Meeting @ Tokyo Summit

Hi,

On Wed, Oct 14, 2015 at 7:36 AM, Fabio Giannetti (fgiannet) 
> wrote:
Guys,
   I have a Cisco room S3 to held a Monasca meeting over the Tokyo Summit.
The time slot is Thursday 4:30pm to 6pm.
Please mark your calendar and see you there.
Fabio


Will this meeting be open to everyone? We are using Monasca at our test 
environment and planning to use it at out production also, would like to hear 
the future plans and development process of it.

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

Re: [openstack-dev] [puppet] Incompatible default parameters

[Clayton O'Neill]

I think the only people that would be affected by the puppet-openstack
module default not matching the keystone default are people that are trying
to retrofit puppet into an already running environment.  Those people
already have a ton of work laid out in front of them, so I’m ok with making
it very slightly more difficult for them (if those people even exist).

However, for existing users of the modules, this is potentially a big pain,
since we already have existing catalogs with the old (wrong) name.

For new users of the module, this might be slightly annoying, but again,
they can override it.

Personally I’d prefer to leave it as is, instead of requiring all existing
users of the modules to change.

On Wed, Oct 21, 2015 at 9:31 AM, Martin Mágr  wrote:

> Greetings,
>
>   I'd like to discuss bug 1506061 ([1]). The main problem I'm trying to
> solve here is that using default parameters of classes cinder::api and
> nova::keystone::auth migration won't work, because Cinder will search for
> endpoint with different name ('Compute service' instead of 'nova'). I've
> submitted fix for that in first patchset of [2], but it was denied as
> backward incompatible change, which I agree with, and instead I just added
> warnings about rename in next cycle [3].
>
>   So the question is if we should start following endpoint naming
> according to Keystone's default catalog or just change default value of
> $nova_catalog_.*info parameters in cinder::api to match endpoint created by
> nova::keystone::auth? I don't mind going one way or another, but I do think
> that default parameters has to create fully functional environment.
>
> Thanks in advance for answers,
> Martin
>
> [1] https://bugs.launchpad.net/puppet-nova/+bug/1506061
> [2] https://review.openstack.org/#/c/222120/1
> [3]
> https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1506061,n,z
> [4] https://review.openstack.org/#/c/219284/2/manifests/api.pp
>
> __
> OpenStack Development Mailing 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] [release] release freeze until after the summit

[Doug Hellmann]

The release management team is going to hold off on releasing
anything else until at least Nov 2, unless there's an emergency,
so we can focus on summit-related preparation and activities.

Doug

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

Re: [openstack-dev] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Vitaly Kramskikh]

Sergii,

Let's move this discussion to the thread "[Fuel] Changing APIs and API
versioning". We need to have this mechanism regardless of our decision on
API versioning.

2015-10-21 20:31 GMT+07:00 Sergii Golovatiuk :

> Vitaliy,
>
> Why do merge API changes without:
>
> 1. Fixing documentation?
> 2. bumping API version?
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Wed, Oct 21, 2015 at 3:08 PM, Vitaly Kramskikh  > wrote:
>
>> Hi,
>>
>> It's yet another time we broke fuelclient by merging a change
>>  in fuel-web repo. Since we
>> are considering moving Fuel UI to a separate repo, and we need to run UI
>> functional tests against changes in nailgun anyway, I think we should start
>> to change our CI so it could run tests from another repo against changes in
>> another repo.
>>
>> Can it be done?
>>
>> --
>> Vitaly Kramskikh,
>> Fuel UI Tech Lead,
>> 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
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
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

[openstack-dev] [NFV][Telco] FYI telcowg-usecases is now in the openstack/ namespace on git.openstack.org

[Steve Gordon]

Hi all,

Just an FYI as I had some questions about this, pursuant to a notice James sent 
out in August [1] the repository has moved from the stackforge/ namespace in 
git to the openstack/ namespace. Open reviews can now be found here:


https://review.openstack.org/#/q/status:open+project:openstack/telcowg-usecases,n,z

You will need to update the remotes for your local copy of the repository, e.g.:

$> git remote -v
gerrit
ssh://sgor...@review.openstack.org:29418/stackforge/telcowg-usecases (fetch)
gerrit
ssh://sgor...@review.openstack.org:29418/stackforge/telcowg-usecases (push)
origingit://git.openstack.org/stackforge/telcowg-usecases (fetch)
origingit://git.openstack.org/stackforge/telcowg-usecases (push)
$> git remote set-url gerrit 
ssh://sgor...@review.openstack.org:29418/openstack/telcowg-usecases
$> git remote set-url origin git://git.openstack.org/openstack/telcowg-usecases

Thanks,

Steve

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/073071.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] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Aleksey Kasatkin]

Sergii,

1. We only have auto-doc for developers which should be changed
automatically.
2. We do not have proper API versioning. We didn't decide yet how to
resolve it. Let's discuss versioning in "[Fuel] Changing APIs and API
versioning" thread.


Aleksey Kasatkin


On Wed, Oct 21, 2015 at 5:26 PM, Vitaly Kramskikh 
wrote:

> Sergii,
>
> Let's move this discussion to the thread "[Fuel] Changing APIs and API
> versioning". We need to have this mechanism regardless of our decision on
> API versioning.
>
> 2015-10-21 20:31 GMT+07:00 Sergii Golovatiuk :
>
>> Vitaliy,
>>
>> Why do merge API changes without:
>>
>> 1. Fixing documentation?
>> 2. bumping API version?
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Wed, Oct 21, 2015 at 3:08 PM, Vitaly Kramskikh <
>> vkramsk...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> It's yet another time we broke fuelclient by merging a change
>>>  in fuel-web repo. Since we
>>> are considering moving Fuel UI to a separate repo, and we need to run UI
>>> functional tests against changes in nailgun anyway, I think we should start
>>> to change our CI so it could run tests from another repo against changes in
>>> another repo.
>>>
>>> Can it be done?
>>>
>>> --
>>> Vitaly Kramskikh,
>>> Fuel UI Tech Lead,
>>> 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
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> 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
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11

[Jeremy Stanley]

On 2015-10-21 10:18:31 -0400 (-0400), Anita Kuno wrote:
[...]
> If folks are willing to help build Gerrit v3, that is wonderful.
> If you would like to talk to Khai on how to get started
> contributing to Gerrit, I'm going out on a limb here and will
> guess he will be supportive of your efforts.

In fact, we even have a work session[*] 9:00am local in the Kinkei
Room on Thursday the 29th to discuss these (and related) topics.
People interested in helping us with our Gerrit implementation
and/or contributing to upstream Gerrit development are welcome!

[*] http://mitakadesignsummit.sched.org/event/c4170a605301dbf9bfa19b9e6a651a87

-- 
Jeremy Stanley

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

[openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Sergey Vasilenko]

Hi, guys!

Now I observe potential-dangerous situation in the providers of
puppet-neutron module. I want share details, because not only
puppet-neutron module may be broken by warnings from Openstack CLI
utilities.


 After updating urllib3 library on my lab, commands like 'neutron net list'
began to throw warnings, like:

> root@node-2:~# neutron net-list
> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
> InsecurePlatformWarning: A true SSLContext object is not available. This
> prevents urllib3 from configuring SSL appropriately and may cause certain
> SSL connections to fail. For more information, see
> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
> .
>   InsecurePlatformWarning
> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
> for a `commonName` for now. This feature is being removed by major browsers
> and deprecated by RFC 2818. (See
> https://github.com/shazow/urllib3/issues/497 for details.)
>   SecurityWarning
>
> +--+---+---+
> | id   | name  | subnets
> |
>
> +--+---+---+
> | 9e1c0866-51f0-4659-8d5c-1c5d0843dab4 | net04_ext |
> 29c952ec-2a13-46fc-a8a1-6e2468a92a95 172.18.171.0/24  |
> | d70b399b-668b-4861-b092-4876ec65df60 | net04 |
> b87fbfd1-0e52-4ab6-8987-286ef0912d1f 192.168.111.0/24 |
>
> +--+---+---+
>

root@node-2:~#


Such urllib3 based warnings is only particular case. Warnings may appear by
another reason while call any Openstack utilities.

Such warnings lead to broke work of puppet-neutron manifests:

> 2015-10-20 16:42:11 +
> /Stage[main]/Main/Openstack::Network::Create_network[net04]/Neutron_network[net04]
> (info): Evaluated in 5.51 seconds
> 2015-10-20 16:42:11 + Puppet (debug): Prefetching neutron resources
> for neutron_subnet
> 2015-10-20 16:42:11 + Puppet (debug): Executing '/usr/bin/neutron
> subnet-list --format=csv --column=id --quote=none'
> 2015-10-20 16:42:13 + Puppet (debug): Executing '/usr/bin/neutron
> subnet-show --format=shell InsecurePlatformWarning'
> 2015-10-20 16:42:16 + Puppet::Type::Neutron_subnet::ProviderNeutron
> (notice): Unable to complete neutron request due to non-fatal error:
> "Execution of '/usr/bin/neutron subnet-show --format=shell
> InsecurePlatformWarning' returned 1:
> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
> InsecurePlatformWarning: A true SSLContext object is not available. This
> prevents urllib3 from configuring SSL appropriately and may cause certain
> SSL connections to fail. For more information, see
> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
> InsecurePlatformWarning
> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
> for a `commonName` for now. This feature is being removed by major browsers
> and deprecated by RFC 2818. (See
> https://github.com/shazow/urllib3/issues/497 for details.)
>   SecurityWarningUnable to find subnet with name 'InsecurePlatformWarning'
> ". Retrying for 7 sec.

 .

Unable to find subnet with name 'InsecurePlatformWarning'
> ". Retrying for 0 sec.
> 2015-10-20 16:42:25 + Puppet (debug): Executing '/usr/bin/neutron
> subnet-show --format=shell InsecurePlatformWarning'
> 2015-10-20 16:42:27 + Puppet (err): Could not prefetch neutron_subnet
> provider 'neutron': Can't retrieve subnet-show because Neutron or Keystone
> API is not available.
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron.rb:153:in
> `get_neutron_resource_attrs'
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron_subnet/neutron.rb:24:in
> `block in instances'
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron_subnet/neutron.rb:23:in
> `collect'
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron_subnet/neutron.rb:23:in
> `instances'
> /etc/puppet/modules/neutron/lib/puppet/provider/neutron_subnet/neutron.rb:43:in
> `prefetch'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:277:in `prefetch'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:167:in
> `prefetch_if_necessary'
> /usr/lib/ruby/vendor_ruby/puppet/transaction.rb:67:in `block in evaluate'


This happens, because Puppet mixing stderr and stdout while execute shell
commands, like

> commands :neutron => 'neutron'

And code, like

>
> https://github.com/openstack/puppet-neutron/blob/master/lib/puppet/provider/neutron.rb#L134-L146

parses stderr output also. Part of warnings gets into incoming data.

IMHO this situation is potential dangerous for all puppet-openstack
modules..

/sv

Re: [openstack-dev] [Neutron] HenryG addition to the Neutron Drivers team

[Edgar Magana]

Well deserved Henry!

Edgar

From: "Armando M." >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, October 20, 2015 at 8:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Neutron] HenryG addition to the Neutron Drivers team

Hi folks,

Henry has been instrumental in many areas of the projects and his crazy working 
hours makes even Kevin and I bow in awe.

Jokes aside, I would like to announce HenryG as a new member of the Neutron 
Drivers team.

Having a propension to attendance, and desire to review of RFEs puts you on the 
right foot to join the group, whose members are rotated regularly so that 
everyone is given the opportunity to grow, and no-one burns out.

The team [1] meets regularly on Tuesdays [2], and anyone is welcome to attend.

Please, join me in welcome Henry to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

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

Re: [openstack-dev] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Sergii Golovatiuk]

Vitaliy,

Why do merge API changes without:

1. Fixing documentation?
2. bumping API version?


--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Wed, Oct 21, 2015 at 3:08 PM, Vitaly Kramskikh 
wrote:

> Hi,
>
> It's yet another time we broke fuelclient by merging a change
>  in fuel-web repo. Since we are
> considering moving Fuel UI to a separate repo, and we need to run UI
> functional tests against changes in nailgun anyway, I think we should start
> to change our CI so it could run tests from another repo against changes in
> another repo.
>
> Can it be done?
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> 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
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11

[Anita Kuno]

On 10/21/2015 08:37 AM, Markus Zoeller wrote:
> "Daniel P. Berrange"  wrote on 10/21/2015 11:29:50 
> AM:
> 
>> From: "Daniel P. Berrange" 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Date: 10/21/2015 11:42 AM
>> Subject: Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11
>>
>> On Tue, Oct 13, 2015 at 05:08:29PM -0700, Zaro wrote:
>>> Hello All,
>>>
>>> The openstack-infra team would like to upgrade from our Gerrit 2.8 to
>>> Gerrit 2.11.  We are proposing to do the upgrade shortly after the
>>> Mitaka summit.  The main motivation behind the upgrade is to allow us
>>> to take advantage of some of the new REST api, ssh commands, and
>>> stream events features.  Also we wanted to stay closer to upstream so
>>> it will be easier to pick up more recent features and fixes.
>>
>> Looking at the release notes I see my most wanted new feature, keyword
>> tagging of changes, is available
>>
>> [quote]
>> Hashtags.
>>
>> Hashtags can be added to changes. The hashtags are stored in git notes 
> and
>> are indexed in the secondary index.
>>
>> This feature requires the notedb to be enabled.
>> [/quote]
>>
>> It is listed as an experimental feature, but I'd really love to see this
>> enabled if at all practical.
>>
>> Regards,
>> Daniel
> 
> +1
> 
> A mockup from the Gerrit folks: http://i.imgur.com/T1azkvk.png
> 
> Regards, Markus Zoeller (markus_z)
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

My reading of the gerrit group thread for design of Gerrit v3 is that
notedb is slated for v3.
https://groups.google.com/forum/#!topic/repo-discuss/Zz8sEbsO36s

Currently we are running 2.8 and working on upgrading to 2.11.

If folks are willing to help build Gerrit v3, that is wonderful. If you
would like to talk to Khai on how to get started contributing to Gerrit,
I'm going out on a limb here and will guess he will be supportive of
your efforts.

Thanks,
Anita.

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

Re: [openstack-dev] [Fuel] Changing APIs and API versioning

[Vitaly Kramskikh]

JFYI: (re-)start of this discussion was instigated by merge of this change
 (and here is revert
).

And this is actually not the first time when we make backward incompatible
changes in our API. AFAIR, the last time it was also about the network
configuration handler. We decided not to consider our API frozen, make the
changes and break backward compatibility. So now is the time to reconsider
this.

API backward compatibility is a must for good software, but we also need to
understand that introducing API versioning is not that easy and will
increase efforts needed to make new changes in nailgun.

I'd go this way:

   - Estimate the priority of introducing API versioning - maybe we have
   other things we should invest our resources to
   - Estimate all the disadvantages this decision might have
   - Fix all the issues in the current API (like this one
   )
   - Implement API versioning support (yes, we don't have this mechanism
   yet, so we can't just "bump API version" like Sergii suggested in another
   thread)
   - Consider the current API as frozen v1, so backward incompatible
   changes (or maybe all the changes?) should go to v2


2015-10-21 20:25 GMT+07:00 Roman Prykhodchenko :

> Hi folks,
>
> I’d like to touch the aspect of Fuel development process that seems to be
> as wrong as possible. That aspect is how we change the API.
>
> The issue is that in Fuel anyone can change API at any point of time
> without even warning the rest of the same component’s team. Relying on this
> kind of API is basically impossible. We constantly have problems when even
> components of Fuel stop working due to unexpected changes in the API.
> Thinking about another software that must be integrated with Fuel is hardly
> possible with the current approach.
>
> As for a grown-up project there is a strong need for Fuel in general and
> for Nailgun in particular to work on a policy for making changes to their
> APIs. Living in OpenStack ecosystem we must at least take a look how it’s
> done in its components and try to do something similar. After working with
> Nova, Keystone, Ironic and other components I would propose to start with
> the following: let’s not make any changes to the API. Instead, let’s create
> a new version of Nailgun’s API that will appear in Fuel 8.0 and make all
> the changes there. That is the thing that will instantaneously make lives
> of other components much easier, if we make it now.
>
> After doing the essential part let’s think about how we are going to live
> with that in the future. There are several APIs in Fuel, the rest of the
> email is only touching Nailgun’s REST API. I can see the things somehow
> like the following:
>
>  - Introduce API documentation by embedding Swagger and Swagger UI.
>The current approach when we leave API docs for documentation team is
> not effective. Swagger generates the documentation and resolves this issue.
>  - After releasing a version of Fuel, it’s API is called stable and frozen
> for any changes, unless they allign API to the documentation or
> documentation to the API.
>  - All changes to a stable APIs must be backported to the stable version
> of Fuel that introduced the corresponding API.
>  - In order to guarantee that a stable API is not changed, Jenkins jobs
> should make automatic checks for every new patch set
>
> Details about all the above mentioned proposals can be discussed in
> separate threads so this one will stay uncluttered. I'd like to also summon
> those OpenStack folks, who tried to resolve the same issue and ask them
> about any common solutions in the ecosystem.
>
>
> - romcheg
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
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

[openstack-dev] [Ironic] BIOS Configuration

[Serge Kovaleff]

Hi all,

I am interested in remote BIOS configuration.
There is "New driver interface for BIOS configuration specification"
https://review.openstack.org/#/c/209612/

Is it possible to implement this without REST API endpoint?

It would be great to access and configure the stuff without any additional
agents or endpoints.

Cheers,
Serge Kovaleff
__
OpenStack Development Mailing 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] [security] The first version of the Logo for Openstack Security Project

[Clark, Robert Graham]

I had looped some people into a previous version of the thread but they've not 
replied yet.

I think we ran into this problem before and got a firm "maybe, depending on 
what it is" from the powers-that-be.

Perhaps we should look at a rough-draft alternative logo while we await a 
verdict?

> -Original Message-
> From: michael mccune [mailto:m...@redhat.com]
> Sent: 21 October 2015 17:27
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [security] The first version of the Logo for 
> Openstack Security Project
> 
> On 10/21/2015 03:54 AM, Michael Xin wrote:
> > Hi, guys:
> > Thanks for your help. We are designing a logo and a flyer for Openstack
> > Security Project. Rachel helped us with the task. Attached is her first
> > version of the logo. Please let us know your feedback.
> >
> > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png
> > Thanks and have a great day.
> 
> hi Michael, thanks to Rachel for putting this together. i like the
> general concept of the openstack logo as a lock. i think the "lock
> parts" could have a little more depth on them.
> 
> you had asked in irc about usage of the openstack logo, i'm not sure.
> but this page, https://www.openstack.org/brand/openstack-logo/ , seems
> to indicate that the usage is pretty limited. in specific, this section
> "You agree that you will not (i) alter or modify the OpenStack Logo as
> provided by the OpenStack Foundation; " seems to indicate that we may
> not be able to use the logo like this. we should probably ask someone
> from the foundation.
> 
> all in all though, a nice effort. many thanks =)
> 
> mike
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Gerrit permissions and Merge rights

[Gal Sagie]

On Wed, Oct 21, 2015 at 7:37 PM, Armando M.  wrote:

>
>
> On 21 October 2015 at 04:12, Gal Sagie  wrote:
>
>> Do we also want to consider Project Kuryr part of this?
>>
>
> No, why would we?
>

[Gal] Because Kuryr is a special project which was created in order to
expose Neutron and its services to containers networking,
 its mission (at least as defined right now) is to bridge the gaps
between containers networking world and Neutron and for doing it
 it already depends on the feature/spec process of Neutron.
 That is why it make sense to me that just like the services
projects, our spec approval process will be handled
 as part of Neutron.


>
>
>> We already started sending Kuryr spec to the Neutron repository and I
>> think it would make sense to manage it
>> as part of Neutron spec process.
>>
>
> No, unless what you are asking are changes to the core. Do you have a
> reference for me to look at?
>
>
  [Gal]   I dont understand what you mean "No" here, first this spec is
sent to Mitaka:
 https://review.openstack.org/#/c/213490/

And as i mentioned above Kuryr spec process depends on Neutron
(and the specs that are sent
to Neutron core)


>> Any opinions on that?
>>
>> Gal.
>>
>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>>
>>> Hi folks,
>>>
>>> During revision of the Neutron teams [1], we made clear that the
>>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>>> (core + *-aas).
>>>
>>> For this reason I made sure that the neutron-specs-core team +2 right
>>> was extended to all the core teams.
>>>
>>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>>> project, you should exercise that vote only for specs that pertain the
>>> project you're core of.
>>>
>>> If I could use this email as a reminder also of the core hierarchy and
>>> lieutenant system we switched to in Liberty ([3]): if you have been made
>>> core by a lieutenant of a sub-system, please use your +2/+A only within
>>> your area of comfort and reach out for help if in doubt.
>>>
>>> Reviews are always welcome though!
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/237180/
>>> [2] https://review.openstack.org/#/admin/groups/314,members
>>> [3]
>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Best Regards ,

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

Re: [openstack-dev] [release] establishing release liaisons for mitaka

[Doug Hellmann]

Excerpts from Lingxian Kong's message of 2015-10-21 16:42:32 +0800:
> Hi, Doug,
> 
> After conversition with Mistral PTL(Renat), I'm willing to be mistral
> liaison to take participate in cross-project release effort on beharf
> of mistral team, so please count me in.

Great, thank you for volunteering!

Please add your contact details to the wiki page [3], and make sure
you have your email client configured so that you will see messages
with the "[release]" topic tag.

Doug

[3] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

> 
> On Wed, Oct 14, 2015 at 11:25 PM, Doug Hellmann  wrote:
> > As with the other cross-project teams, the release management team
> > relies on liaisons from each project to be available for coordination of
> > work across all teams. It's the start of a new cycle, so it's time to
> > find those liaison volunteers.
> >
> > We are working on updating the release documentation as part of the
> > Project Team Guide. Release liaison responsibilities are documented in
> > [0], and we will update that page with more details over time.
> >
> > In the past we have defaulted to having the PTL act as liaison if no
> > alternate is specified, and we will continue to do that during Mitaka.
> > If you plan to delegate release work to a liaison, especially for
> > submitting release requests, please update the wiki [1] to provide their
> > contact information. If you plan to serve as your team's liaison, please
> > add your contact details to the page.
> >
> > Thanks,
> > Doug
> >
> > [0] 
> > http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons
> > [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
> >
> > __
> > OpenStack Development Mailing 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] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Aleksandra Fedorova]

Hi, Vitaly,

there is nothing to prevent us from triggering test based on event in
one project but checking out the code from another.

So you can setup job triggered for patchset-created event in commit to
fuel-web/ repo. Then in this job you checkout both: code from fuel-web
and code from python-fuelclient in different subfolders, then run a
test, get result and vote on patchset to fuel-web repository.

python-fuelclient failures are not new indeed, and we have a bug [1]
for 8.0 milestone to implement this kind of job. It will be much
easier for CI team if we get initial implementation of the test so we
can build a job on top. If you have some spare cycles - please
participate, feel free to send a patch to jenkins-jobs repository
directly [2] or comment on bug.

[1] https://bugs.launchpad.net/fuel/+bug/1466897
[2] https://review.fuel-infra.org/#/admin/projects/fuel-infra/jenkins-jobs

On Wed, Oct 21, 2015 at 4:08 PM, Vitaly Kramskikh
 wrote:
> Hi,
>
> It's yet another time we broke fuelclient by merging a change in fuel-web
> repo. Since we are considering moving Fuel UI to a separate repo, and we
> need to run UI functional tests against changes in nailgun anyway, I think
> we should start to change our CI so it could run tests from another repo
> against changes in another repo.
>
> Can it be done?
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> 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
>


-- 
Aleksandra Fedorova
Fuel CI Engineer
bookwar

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

Re: [openstack-dev] [ceilometer][aodh] proposal to add Ryota Mibu to Aodh core

[gord chung]

thanks for the feedback folks.

i'd like to welcome Ryota to the Aodh core team. thank you for all the 
continued effort in building alarming functionality in OpenStack!


On 16/10/2015 8:59 AM, gord chung wrote:
sorry, as we usually do, please comment on gerrit[1]. if you cannot, 
then please comment here.


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

On 16/10/15 08:39 AM, gord chung wrote:

hi,

i'd like to nominate Ryota Mibu to the Aodh core team. he has been an 
active participant in Aodh and leads the Event alarms work done 
there. he also brings good insight related to NFV use case.


patches:
https://review.openstack.org/#/q/owner:%22Ryota+MIBU%22+project:openstack/aodh,n,z 



reviews:
https://review.openstack.org/#/q/reviewer:%22Ryota+MIBU%22+project:openstack/aodh,n,z 



cheers,





--
gord


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

Re: [openstack-dev] [Magnum] Coe components status

[Egor Guz]

Vikas,

Could you clarify what do you mean under ’status’? I don’t seed this command in 
kubectl, so I assume it is get or describe?
Also for Docker, is it info, inspect or stats? We can get app/container details 
through Marathon API in Mesos, but it’s very depend what information we are 
looking for ;)

My two cents, I think we should implement/found common ground between 'kub 
describe’, ‘docker inspect’ and 'curl http://${MASTER_IP}:8080/v2/tasks' first. 
These commands
are very useful for troubleshooting.

About 'magnum container’ command for all COEs, we should definitely discuss 
this topic during summit. But challenge here that Marathon/Mesos app/container 
definition is
very different form Kub model.

—
Egor

From: Vikas Choudhary 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, October 20, 2015 at 20:56
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Magnum] Coe components status

@ Eli ,

I will look into how to support this feature for other COEs also(mesos and 
swarm). But anyways Magnum's goal is to provide users *atleast* what other coes 
are providing (if not something extra). All coes dont have common features, so 
we cant be very strict on providing common interface apis for all coes. For 
example "magnum container" commands work only with swarm not k8s or mesos.
It will not be justified if k8s is providing a way to monitor at more granular 
level but magnum will not allow user to use it just beacuse other coes does not 
provide this feature.

Agree that it will be nice if could support this feature for all. I will prefer 
to start with k8s first and if similar feature is supported by mesos and swarm 
also, incrementally will implement that also.

Regards
Vikas Choudhary

On Wed, Oct 21, 2015 at 6:50 AM, Qiao,Liyong 
> wrote:
hi Vikas,
thanks for propose this changes, I wonder if you can show some examples for 
other coes we currently supported:
swarm, mesos ?

if we propose a public api like you proposed, we'd better to support all coes 
instead of coe specific.

thanks
Eli.


On 2015年10月20日 18:14, Vikas Choudhary wrote:
Hi Team,

I would appreciate any opinion/concern regarding "coe-component-status" feature 
implementation [1].

For example in k8s, using API api/v1/namespaces/{namespace}/componentstatuses, 
status of each k8s component can be queried. My approach would be to provide a 
command in magnum like "magnum coe-component-status" leveraging coe provided 
rest api and result will be shown to user.

[1] https://blueprints.launchpad.net/magnum/+spec/coe-component-status



-Vikas Choudhary



__
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


--
BR, Eli(Li Yong)Qiao

__
OpenStack Development Mailing 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] [rally] Rally boot tests fails with Error Forbidden: It is not allowed to create an interface on external networks

[Aleksandr Maretskiy]

Behzad, please run rally task start with `--debug' option and then provide
us with some details (traceback, etc) about this error.

Also Yair suggested to put `"auto_assign_nic": true' into scenario config -
that is good idea.
Get rid of `use_floatingip' - this parameter is not used for this scenario.

On Wed, Oct 21, 2015 at 6:23 PM, Behzad Dastur 
wrote:

> Thanks Yair,
> I will dig into this more. I did try the "network" context, but same error.
>
> regards
> Behzad
>
> On Tue, Oct 20, 2015 at 12:53 PM, Yair Fried  wrote:
>
>>
>>
>> On Tue, Oct 20, 2015 at 8:39 PM, Behzad Dastur 
>> wrote:
>>
>>> Hi Yair,
>>> The rally version I am using is 0.1.2
>>>
>>> > rally --version
>>> 0.1.2
>>>
>>> Also the task file is as shown below. Do you have an example of the
>>> "network" context to skip creation on the interface on the xternal network?
>>>
>> have you seen the plugin reference?
>> https://rally.readthedocs.org/en/latest/plugin/plugin_reference.html
>> Looks like there's also existing_network [context] but I'm unfamiliar
>> with it.
>>
>>> vagrant@rally:~/rally$ more /vagrant/boot.json
>>>
>>> {% set flavor_name = flavor_name or "m1.tiny" %}
>>>
>>> {
>>>
>>> "NovaServers.boot_server": [
>>>
>>> {
>>>
>>> "args": {
>>>
>>> "flavor": {
>>>
>>> "name": "{{flavor_name}}"
>>>
>>> },
>>>
>> "auto_assign_nic": true,
>>
>>> "image": {
>>>
>>> "name": "cirros-0.3.1-x86_64"
>>>
>>> },
>>>
>>> "use_floatingip": false
>>>
>> I think this should be true (or maybe even removed)
>>
>>> },
>>>
>>> "runner": {
>>>
>>> "type": "constant",
>>>
>>> "times": 10,
>>>
>>> "concurrency": 2
>>>
>>> },
>>>
>>> "context": {
>>>
>> "network": {"networks_per_tenant": 1},
>>
>>> "users": {
>>>
>>> "tenants": 3,
>>>
>>> "users_per_tenant": 2
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>> ]
>>>
>>> }
>>>
>>> regards,
>>> Behzad
>>>
>>> Date: Tue, 20 Oct 2015 15:04:46 +0300
>>> From: Yair Fried 
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: Re: [openstack-dev] [rally] Rally boot tests fails with Error
>>> Forbidden: It is not allowed to create an interface on external
>>> networks
>>> Message-ID:
>>> 

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

[michael mccune]

On 10/21/2015 03:54 AM, Michael Xin wrote:

Hi, guys:
Thanks for your help. We are designing a logo and a flyer for Openstack
Security Project. Rachel helped us with the task. Attached is her first
version of the logo. Please let us know your feedback.

http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png
Thanks and have a great day.


hi Michael, thanks to Rachel for putting this together. i like the 
general concept of the openstack logo as a lock. i think the "lock 
parts" could have a little more depth on them.


you had asked in irc about usage of the openstack logo, i'm not sure. 
but this page, https://www.openstack.org/brand/openstack-logo/ , seems 
to indicate that the usage is pretty limited. in specific, this section 
"You agree that you will not (i) alter or modify the OpenStack Logo as 
provided by the OpenStack Foundation; " seems to indicate that we may 
not be able to use the logo like this. we should probably ask someone 
from the foundation.


all in all though, a nice effort. many 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] [Neutron] Gerrit permissions and Merge rights

[Armando M.]

On 21 October 2015 at 04:12, Gal Sagie  wrote:

> Do we also want to consider Project Kuryr part of this?
>

No, why would we?


> We already started sending Kuryr spec to the Neutron repository and I
> think it would make sense to manage it
> as part of Neutron spec process.
>

No, unless what you are asking are changes to the core. Do you have a
reference for me to look at?


>
> Any opinions on that?
>
> Gal.
>
> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>
>> Hi folks,
>>
>> During revision of the Neutron teams [1], we made clear that the
>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>> (core + *-aas).
>>
>> For this reason I made sure that the neutron-specs-core team +2 right was
>> extended to all the core teams.
>>
>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>> project, you should exercise that vote only for specs that pertain the
>> project you're core of.
>>
>> If I could use this email as a reminder also of the core hierarchy and
>> lieutenant system we switched to in Liberty ([3]): if you have been made
>> core by a lieutenant of a sub-system, please use your +2/+A only within
>> your area of comfort and reach out for help if in doubt.
>>
>> Reviews are always welcome though!
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/237180/
>> [2] https://review.openstack.org/#/admin/groups/314,members
>> [3]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing 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] HenryG addition to the Neutron Drivers team

[Armando M.]

On 21 October 2015 at 02:01, Ihar Hrachyshka  wrote:

>
> > On 21 Oct 2015, at 05:14, Armando M.  wrote:
> >
> > Hi folks,
> >
> > Henry has been instrumental in many areas of the projects and his crazy
> working hours makes even Kevin and I bow in awe.
> >
> > Jokes aside, I would like to announce HenryG as a new member of the
> Neutron Drivers team.
> >
> > Having a propension to attendance, and desire to review of RFEs puts you
> on the right foot to join the group, whose members are rotated regularly so
> that everyone is given the opportunity to grow, and no-one burns out.
> >
> > The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
> attend.
> >
> > Please, join me in welcome Henry to the team.
>
> Nice addition. :)
>
> Do we have criteria for neutron-drivers team members documented? Or is it
> a mere ‘regularly attending the meetings, be mindful and apply common
> sense’?
>

I knew someone was going to ask that. I'll elaborate further, I already
have something in WIP.

Cheers,
Armando


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

Re: [openstack-dev] [ironic] [horizon] ironic panels

[Beth Elwell]

On 21/10/2015 01:48, Jim Rollenhagen wrote:

On Tue, Oct 20, 2015 at 04:50:04PM +0100, Beth Elwell wrote:

Hi Jim,

I have replied inline to your comments below:

On 19/10/2015 19:38, Jim Rollenhagen wrote:

On Mon, Oct 19, 2015 at 07:05:04PM +0100, Beth Elwell wrote:

Hi all,

I am currently in the process of writing an Ironic panel in Horizon
upstream. It was originally intended for this panel to be written in
Angular JS, however, as I understand, no horizon angular work will
merge for several months, and 2-3 panels (of which ironic is not one)
are being moved to the feature branch to iterate on the design pattern
that they want to use to implement the angular.

With regard to the ironic panel, this means that in order to implement
it in angular, it will take weeks or perhaps months to merge and even
when it does, it may well need to be rewritten to follow design patterns
being set at the moment.

Therefore I propose that I continue to develop this as a Horizon python
panel as a short term solution to allow a UI to exist for our users of
Ironic ASAP and longer term make use of the ironic webclient and the
work that krotscheck is currently doing on that.

I would appreciate feedback with regard to whether the ironic community
are happy for me to continue on with developing a horizon panel or would
like me to work on an angular panel.

In general, I like the idea of "get a web interface to users quickly",
and in that spirit I think building a horizon panel is the right thing
to do.

I do love the webclient work; I think it's great. However, considering
that (as far as I know) there's only two people working on Ironic web
interfaces, is it valuable to be working on two different web interfaces
right now? In the worst case:

I have had contact from another party interested in helping get a horizon
panel up and running quickly and so it is definitely doable to have that
being worked on as well as the work on the webclient.

* horizon panel will be built
* webclient will also be built
* horizon will figure out angular stuff
* webclient will be re-written to work with horizon
* webclient will likely take significant time to merge into horizon
* old horizon panel will be deprecated
* (in time) old horizon panel will be removed

And in the best case, only the rewrite step is skipped, and maybe the
merge into horizon won't take long. There's also a question about how
much different the two are, and how large of a leap that is for users.

That seems like a lot of extra effort and maintenance for an entire
team; let alone two people. So I question if it's worth working on the
webclient, or punting on that until horizon is ready, and then
refactoring the horizon panel into angular.

Is there a clear benefit to having both worked on in parallel?

As I see it they ultimately fulfill different purposes and therefore
developing both is not a waste of resources or time. The panel is a short
term solution to fulfill a user requirement for a user interface within
Horizon. The webclient is a long term mission to create independent API
libraries in javascript in order to make openstack more composable.

Okay, after reading this and talking with krotscheck in IRC:

* The horizon panel is clearly valuable, as many users use Horizon. We
   should support that.

* The ironic-webclient work is clearly valuable, as we support running
   Ironic standalone, and a standalone web UI would be great to have for
   that.

* I'm not opinionated whether "independent API libraries in Javascript
   in order to make OpenStack more composable" is valuable. It seems like
   it is, assuming there's a use case for that. The clear use case to me
   is to allow Horizon competitors to be built, which seems useful for
   folks that don't want to or care to use Horizon.

At any rate, I agree the horizon panel should be worked on - let's get
our users a UI.


Following the original email I have spoken further with the Horizon 
teams. In assessing the state of my existing work and theirs on the 
angular panel have got to, it seems pointless to remake a Django horizon 
panel, and in so doing go backwards, when one in angular already 
virtually exists in full now.


After discussion with David Lyle from horizon I will be converting the 
angular panel to a plugin that will be a significantly faster effort 
than starting another panel from scratch in Django. As I understand, 
this will have much the same effect as a panel within horizon - our 
users will have an ironic UI allowing them to access ironic from within 
horizon and we will be able to reuse most of the existing code that has 
already been written to do so to avoid replication of the same thing in 
just a different language.


// jim

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

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Kyle Mestery]

On Wed, Oct 21, 2015 at 11:37 AM, Armando M.  wrote:

>
>
> On 21 October 2015 at 04:12, Gal Sagie  wrote:
>
>> Do we also want to consider Project Kuryr part of this?
>>
>
> No, why would we?
>
>
The reason to consider it is because Kuryr is a sub-project of Neutron, and
they are doing their spec submissions following the Neutron guidelines.
Adding the kuryr-core gerrit group to be on part with the *aas repos makes
sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
reviews in the neutron-specs repository, then adding them makes sense too.


> We already started sending Kuryr spec to the Neutron repository and I
>> think it would make sense to manage it
>> as part of Neutron spec process.
>>
>
> No, unless what you are asking are changes to the core. Do you have a
> reference for me to look at?
>
>
See above, perhaps I answered this for you.


>
>> Any opinions on that?
>>
>> Gal.
>>
>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>>
>>> Hi folks,
>>>
>>> During revision of the Neutron teams [1], we made clear that the
>>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>>> (core + *-aas).
>>>
>>> For this reason I made sure that the neutron-specs-core team +2 right
>>> was extended to all the core teams.
>>>
>>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>>> project, you should exercise that vote only for specs that pertain the
>>> project you're core of.
>>>
>>> If I could use this email as a reminder also of the core hierarchy and
>>> lieutenant system we switched to in Liberty ([3]): if you have been made
>>> core by a lieutenant of a sub-system, please use your +2/+A only within
>>> your area of comfort and reach out for help if in doubt.
>>>
>>> Reviews are always welcome though!
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/237180/
>>> [2] https://review.openstack.org/#/admin/groups/314,members
>>> [3]
>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>> __
>> OpenStack Development Mailing 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] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Stanislaw Bogatkin]

I spoken with Sergii about this and prepared a patch for get rid of
SecurityWarning [0] - it was easy. But we can't get rid from
InsecurePlatformWarning
so easy way. I see next options:
1. Update python version as [1] said - should be hard task
2. Downgrade urllib version to one without such warning - is a bad idea, as
for me
3. Rewrite code to use non-standard ssl python module (pyOpenSSL, for
example) - may be a massive task
4. Use something like 2>/dev/null to don't show stderr when call the
command - doesn't looks good, cause problem can be seen on other places (I
saw similar problems with keystone provider, for example)
5. Rewrite code to split stderr/stdout, as Sergey proposed - is a most
reasonable idea, as for me.

[0] https://review.openstack.org/#/c/237379
[1]
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning


On Wed, Oct 21, 2015 at 10:02 AM, Sergey Vasilenko 
wrote:

> Hi, guys!
>
> Now I observe potential-dangerous situation in the providers of
> puppet-neutron module. I want share details, because not only
> puppet-neutron module may be broken by warnings from Openstack CLI
> utilities.
>
>
>  After updating urllib3 library on my lab, commands like 'neutron net
> list' began to throw warnings, like:
>
>> root@node-2:~# neutron net-list
>> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
>> InsecurePlatformWarning: A true SSLContext object is not available. This
>> prevents urllib3 from configuring SSL appropriately and may cause certain
>> SSL connections to fail. For more information, see
>> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
>> .
>>   InsecurePlatformWarning
>> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
>> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
>> for a `commonName` for now. This feature is being removed by major browsers
>> and deprecated by RFC 2818. (See
>> https://github.com/shazow/urllib3/issues/497 for details.)
>>   SecurityWarning
>>
>> +--+---+---+
>> | id   | name  | subnets
>>   |
>>
>> +--+---+---+
>> | 9e1c0866-51f0-4659-8d5c-1c5d0843dab4 | net04_ext |
>> 29c952ec-2a13-46fc-a8a1-6e2468a92a95 172.18.171.0/24  |
>> | d70b399b-668b-4861-b092-4876ec65df60 | net04 |
>> b87fbfd1-0e52-4ab6-8987-286ef0912d1f 192.168.111.0/24 |
>>
>> +--+---+---+
>>
>
> root@node-2:~#
>
>
> Such urllib3 based warnings is only particular case. Warnings may appear
> by another reason while call any Openstack utilities.
>
> Such warnings lead to broke work of puppet-neutron manifests:
>
>> 2015-10-20 16:42:11 +
>> /Stage[main]/Main/Openstack::Network::Create_network[net04]/Neutron_network[net04]
>> (info): Evaluated in 5.51 seconds
>> 2015-10-20 16:42:11 + Puppet (debug): Prefetching neutron resources
>> for neutron_subnet
>> 2015-10-20 16:42:11 + Puppet (debug): Executing '/usr/bin/neutron
>> subnet-list --format=csv --column=id --quote=none'
>> 2015-10-20 16:42:13 + Puppet (debug): Executing '/usr/bin/neutron
>> subnet-show --format=shell InsecurePlatformWarning'
>> 2015-10-20 16:42:16 + Puppet::Type::Neutron_subnet::ProviderNeutron
>> (notice): Unable to complete neutron request due to non-fatal error:
>> "Execution of '/usr/bin/neutron subnet-show --format=shell
>> InsecurePlatformWarning' returned 1:
>> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
>> InsecurePlatformWarning: A true SSLContext object is not available. This
>> prevents urllib3 from configuring SSL appropriately and may cause certain
>> SSL connections to fail. For more information, see
>> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
>> InsecurePlatformWarning
>> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
>> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
>> for a `commonName` for now. This feature is being removed by major browsers
>> and deprecated by RFC 2818. (See
>> https://github.com/shazow/urllib3/issues/497 for details.)
>>   SecurityWarningUnable to find subnet with name 'InsecurePlatformWarning'
>> ". Retrying for 7 sec.
>
>  .
>
> Unable to find subnet with name 'InsecurePlatformWarning'
>> ". Retrying for 0 sec.
>> 2015-10-20 16:42:25 + Puppet (debug): Executing '/usr/bin/neutron
>> subnet-show --format=shell InsecurePlatformWarning'
>> 2015-10-20 16:42:27 + Puppet (err): Could not prefetch neutron_subnet
>> provider 'neutron': Can't retrieve subnet-show because Neutron or Keystone
>> API is not available.
>> /etc/puppet/modules/neutron/lib/puppet/provider/neutron.rb:153:in
>> 

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Armando M.]

On 21 October 2015 at 10:29, Kyle Mestery  wrote:

> On Wed, Oct 21, 2015 at 12:08 PM, Armando M.  wrote:
>
>>
>>
>> On 21 October 2015 at 09:53, Kyle Mestery  wrote:
>>
>>> On Wed, Oct 21, 2015 at 11:37 AM, Armando M.  wrote:
>>>


 On 21 October 2015 at 04:12, Gal Sagie  wrote:

> Do we also want to consider Project Kuryr part of this?
>

 No, why would we?


>>> The reason to consider it is because Kuryr is a sub-project of Neutron,
>>> and they are doing their spec submissions following the Neutron guidelines.
>>> Adding the kuryr-core gerrit group to be on part with the *aas repos makes
>>> sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
>>> reviews in the neutron-specs repository, then adding them makes sense too.
>>>
>>
>> I don't believe this is the road we set ourselves on when we started the
>> decomp/stadium. We wanted a clear separation of concerns and I don't see
>> how going down this path is going to help us achieve that.
>>
>> I don't see the grounds to have such an abrupt change in direction right
>> now, especially for the level of work that that would imply and the
>> pressure that would put on the drivers team. Anyone is free to review and
>> contribute where it matters for them, and location should not prevent them
>> from doing so.
>>
>>
> I was merely implying that since these projects are part of neutron, and
> they have specs, keeping them in one place makes sense. And by doing that,
> we'd need to give them +2 powers for their core reviewers. But, I'm fine
> with leaving things the way they are and having them put their specs in
> their devref. But we should update the devref in Neutron to reflect this,
> e.g. that we don't expect specs in neutron-specs for things outside
> [neutron, neutron-fwaas, neutron-lbaas, neutron-vpnaas].
>
>

IMO, it's pretty clear from here [1], which I revised in the context of
[2]. Not sure if there's anything else that's left to misunderstanding.

[1]
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team
[2] https://review.openstack.org/#/c/237180/



>
>>>
 We already started sending Kuryr spec to the Neutron repository and I
> think it would make sense to manage it
> as part of Neutron spec process.
>

 No, unless what you are asking are changes to the core. Do you have a
 reference for me to look at?


>>> See above, perhaps I answered this for you.
>>>
>>
>>>

> Any opinions on that?
>
> Gal.
>
> On Tue, Oct 20, 2015 at 11:10 PM, Armando M. 
> wrote:
>
>> Hi folks,
>>
>> During revision of the Neutron teams [1], we made clear that the
>> neutron-specs repo is to be targeted by specs for all the Neutron 
>> projects
>> (core + *-aas).
>>
>> For this reason I made sure that the neutron-specs-core team +2 right
>> was extended to all the core teams.
>>
>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>> project, you should exercise that vote only for specs that pertain the
>> project you're core of.
>>
>> If I could use this email as a reminder also of the core hierarchy
>> and lieutenant system we switched to in Liberty ([3]): if you have been
>> made core by a lieutenant of a sub-system, please use your +2/+A only
>> within your area of comfort and reach out for help if in doubt.
>>
>> Reviews are always welcome though!
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/237180/
>> [2] https://review.openstack.org/#/admin/groups/314,members
>> [3]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
>
> __
> OpenStack Development Mailing 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] [cinder] No meeting Oct 28th

[Sean McGinnis]

It seems someone always asks during the Summit, so this is an attempt to
make sure it is known.

Due to the Design Summit taking place next week, Cinder will not be
holding its regular Wednesday meeting. We will resume normal meetings
the following week.

Thanks!
Sean McGinnis (smcginnis)


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

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Kyle Mestery]

On Wed, Oct 21, 2015 at 12:34 PM, Armando M.  wrote:

>
>
> On 21 October 2015 at 10:29, Kyle Mestery  wrote:
>
>> On Wed, Oct 21, 2015 at 12:08 PM, Armando M.  wrote:
>>
>>>
>>>
>>> On 21 October 2015 at 09:53, Kyle Mestery  wrote:
>>>
 On Wed, Oct 21, 2015 at 11:37 AM, Armando M.  wrote:

>
>
> On 21 October 2015 at 04:12, Gal Sagie  wrote:
>
>> Do we also want to consider Project Kuryr part of this?
>>
>
> No, why would we?
>
>
 The reason to consider it is because Kuryr is a sub-project of Neutron,
 and they are doing their spec submissions following the Neutron guidelines.
 Adding the kuryr-core gerrit group to be on part with the *aas repos makes
 sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
 reviews in the neutron-specs repository, then adding them makes sense too.

>>>
>>> I don't believe this is the road we set ourselves on when we started the
>>> decomp/stadium. We wanted a clear separation of concerns and I don't see
>>> how going down this path is going to help us achieve that.
>>>
>>> I don't see the grounds to have such an abrupt change in direction right
>>> now, especially for the level of work that that would imply and the
>>> pressure that would put on the drivers team. Anyone is free to review and
>>> contribute where it matters for them, and location should not prevent them
>>> from doing so.
>>>
>>>
>> I was merely implying that since these projects are part of neutron, and
>> they have specs, keeping them in one place makes sense. And by doing that,
>> we'd need to give them +2 powers for their core reviewers. But, I'm fine
>> with leaving things the way they are and having them put their specs in
>> their devref. But we should update the devref in Neutron to reflect this,
>> e.g. that we don't expect specs in neutron-specs for things outside
>> [neutron, neutron-fwaas, neutron-lbaas, neutron-vpnaas].
>>
>>
>
> IMO, it's pretty clear from here [1], which I revised in the context of
> [2]. Not sure if there's anything else that's left to misunderstanding.
>
>
I think this [1] helps to make it 100% clearer, at least to me.

[1] https://review.openstack.org/238190


> [1]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team
> [2] https://review.openstack.org/#/c/237180/
>
>
>
>>

> We already started sending Kuryr spec to the Neutron repository and I
>> think it would make sense to manage it
>> as part of Neutron spec process.
>>
>
> No, unless what you are asking are changes to the core. Do you have a
> reference for me to look at?
>
>
 See above, perhaps I answered this for you.

>>>

>
>> Any opinions on that?
>>
>> Gal.
>>
>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M. 
>> wrote:
>>
>>> Hi folks,
>>>
>>> During revision of the Neutron teams [1], we made clear that the
>>> neutron-specs repo is to be targeted by specs for all the Neutron 
>>> projects
>>> (core + *-aas).
>>>
>>> For this reason I made sure that the neutron-specs-core team +2
>>> right was extended to all the core teams.
>>>
>>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>>> project, you should exercise that vote only for specs that pertain the
>>> project you're core of.
>>>
>>> If I could use this email as a reminder also of the core hierarchy
>>> and lieutenant system we switched to in Liberty ([3]): if you have been
>>> made core by a lieutenant of a sub-system, please use your +2/+A only
>>> within your area of comfort and reach out for help if in doubt.
>>>
>>> Reviews are always welcome though!
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/237180/
>>> [2] https://review.openstack.org/#/admin/groups/314,members
>>> [3]
>>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>>
>> __
>> OpenStack Development Mailing 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] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

[Davanum Srinivas]

Sean,

If you are using the GMR code from oslo-incubator, please switch over to
the new oslo.service. I don't see any pending reviews.

Thanks,
-- Dims

On Wed, Oct 21, 2015 at 1:29 PM, Sean McGinnis 
wrote:

> On Wed, Oct 21, 2015 at 02:43:39PM +0200, Kashyap Chamarthy wrote:
> > Background
> > --
> >
> > Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
> > mechanism that allows one to capture the current state of a Nova
> > process/executable (e.g. `nova-compute`, `nova-api`, etc).
> >
> > The way to generate the error report is to supply the 'User-defined
> > signal', SIGUSR1, when killing a Nova process.  E.g.
> >
> > $ kill -USR1 `pgrep nova-compute`
> >
> > which results in GMR being printed to your standard error ('stderr')
> > stream, wherever it ends up being redirected to (e.g. to a corresponding
> > Nova process-specific log file, otherwise, on systemd-enabled systems,
> > to its journal).
> >
> >
> > Change in Mitaka (and above)
> > 
> >
> > From the upcoming Mitaka release onwards, the default expected UNIX
> > signal to generate GMR has been changed[1] from USR1 to USR2 (another
> > User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
> > for its own purpose.
> >
> > So, to generate GMR, from Mitaka release:
> >
> > $ kill -USR2 `pgrep nova-compute`
> >
> > A corresponding Nova documentation change[2] has been submitted to
> > reflect this new reality.
>
>
> Do you know if anyone is working on updating all projects that GMR was
> added to? Or should we each look at our own projects and make the
> necessary changes?
>
>
> >
> >
> > [1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
> > Use SIGUSR2 instead of SIGUSR1
> > [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
> > instructions to generate GMR error reports
> >
> >
> > [*] References
> > --
> >
> > Related reading:
> >
> > - http://docs.openstack.org/developer/nova/gmr.html
> > - http://docs.openstack.org/developer/oslo.reports/usage.html
> > - https://wiki.openstack.org/wiki/GuruMeditationReport
> > -
> https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
> >
> > --
> > /kashyap
> >
> >
> __
> > OpenStack Development Mailing 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
>



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

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Kyle Mestery]

On Wed, Oct 21, 2015 at 12:08 PM, Armando M.  wrote:

>
>
> On 21 October 2015 at 09:53, Kyle Mestery  wrote:
>
>> On Wed, Oct 21, 2015 at 11:37 AM, Armando M.  wrote:
>>
>>>
>>>
>>> On 21 October 2015 at 04:12, Gal Sagie  wrote:
>>>
 Do we also want to consider Project Kuryr part of this?

>>>
>>> No, why would we?
>>>
>>>
>> The reason to consider it is because Kuryr is a sub-project of Neutron,
>> and they are doing their spec submissions following the Neutron guidelines.
>> Adding the kuryr-core gerrit group to be on part with the *aas repos makes
>> sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
>> reviews in the neutron-specs repository, then adding them makes sense too.
>>
>
> I don't believe this is the road we set ourselves on when we started the
> decomp/stadium. We wanted a clear separation of concerns and I don't see
> how going down this path is going to help us achieve that.
>
> I don't see the grounds to have such an abrupt change in direction right
> now, especially for the level of work that that would imply and the
> pressure that would put on the drivers team. Anyone is free to review and
> contribute where it matters for them, and location should not prevent them
> from doing so.
>
>
I was merely implying that since these projects are part of neutron, and
they have specs, keeping them in one place makes sense. And by doing that,
we'd need to give them +2 powers for their core reviewers. But, I'm fine
with leaving things the way they are and having them put their specs in
their devref. But we should update the devref in Neutron to reflect this,
e.g. that we don't expect specs in neutron-specs for things outside
[neutron, neutron-fwaas, neutron-lbaas, neutron-vpnaas].


>
>>
>>> We already started sending Kuryr spec to the Neutron repository and I
 think it would make sense to manage it
 as part of Neutron spec process.

>>>
>>> No, unless what you are asking are changes to the core. Do you have a
>>> reference for me to look at?
>>>
>>>
>> See above, perhaps I answered this for you.
>>
>
>>
>>>
 Any opinions on that?

 Gal.

 On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:

> Hi folks,
>
> During revision of the Neutron teams [1], we made clear that the
> neutron-specs repo is to be targeted by specs for all the Neutron projects
> (core + *-aas).
>
> For this reason I made sure that the neutron-specs-core team +2 right
> was extended to all the core teams.
>
> Be mindful, use your +2 rights with care: if you are core on a *-aas
> project, you should exercise that vote only for specs that pertain the
> project you're core of.
>
> If I could use this email as a reminder also of the core hierarchy and
> lieutenant system we switched to in Liberty ([3]): if you have been made
> core by a lieutenant of a sub-system, please use your +2/+A only within
> your area of comfort and reach out for help if in doubt.
>
> Reviews are always welcome though!
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/237180/
> [2] https://review.openstack.org/#/admin/groups/314,members
> [3]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


 --
 Best Regards ,

 The G.


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

[openstack-dev] AUTO: Alon Marx is out of the office (returning 11/02/2015)

[ALONMA]

I am out of the office until 11/02/2015.

I will be available occasionally on email.

For any urgent matters please contact Ohad Atia.


Note: This is an automated response to your message  "OpenStack-dev Digest,
Vol 42, Issue 56" sent on 10/21/15 5:10:27 AM.

This is the only notification you will receive while this person is away.


__
OpenStack Development Mailing 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][Cinder] Multi-attach volume help needed

[Ildikó Váncsa]

Hi Folks,

The work has been ongoing for a while now to implement the feature to support 
attaching a single volume to multiple VM instances.

This work impacts both Nova and Cinder. We are in quite good shape with the 
implementation, but it is still far for completion and we temporarily ran out 
of resources and looking for hands to help out. We have the following items 
left:

* Cinder
  * Blueprint implementation finished on server and client side too
  * Volume detach has a bug, which makes the feature unusable at the moment. A 
proposed fix is up for review, but we couldn't reach a consensus yet regarding 
solution: https://review.openstack.org/#/c/198400/ 

* Nova
  * Spec is re-proposed for Mitaka
* https://review.openstack.org/#/c/212508/ 
* Encryption needs to be sorted out
  * Code for Nova side is up for review
* 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/volume-multi-attach,n,z
* REST API is not finished
* Needs rebase and code review

* Testing
  * Tempest coverage is missing
  * Manual/functional testing is missing

There will be a Nova - Cinder cross project session during the Summit, which 
can be a good opportunity to discuss the missing pieces and identified issues: 
https://mitakadesignsummit.sched.org/event/eb6adc828485d7bce0cba6654cc33156#.VifQYZeLJ4M
 

If you are interested in this feature, we could use some help in clarifying the 
encryption in the spec, fixing the Cinder bug, finish the Nova patches or 
adding Tempest coverage. If you would like to jump in and start with any tasks, 
please let me know. If you will be in Tokyo next week we can either meet on the 
session I linked above or we can set up a meeting separately to discuss how to 
move forward, otherwise we can discuss next steps in either mail or IRC.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

__
OpenStack Development Mailing 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-barbican-authenticate-keystone-barbican-command

[Dolph Mathews]

On Wed, Oct 21, 2015 at 6:26 AM, Dave McCowan (dmccowan)  wrote:

> Hi Arif--
> Are you using Keystone for authentication?
> If so, you need to get an authentication token from Keystone and add
> it as a header to your curl command: -H "X-Auth-Token:*$TOKEN*".
> You do not need to specify the project ID (-H 'X-Project-Id:12345').
> The project ID will be based on your Keystone user's project ID.
>

++ To add to that, X-Project-Id is provided to Barbican by
keystonemiddleware.auth_token (along with the rest of your authorization
context) after your X-Auth-Token is authenticated. If you're not using
keystonemiddleware.auth_token, you could specify X-Project-Id yourself, and
Barbican would blindly trust you.


> --Dave
>
> From: OpenStack Mailing List Archive 
> Reply-To: "openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, October 21, 2015 at 3:11 AM
> To: "openstack-dev@lists.openstack.org"  >
> Subject: [openstack-dev]
> openstack-barbican-authenticate-keystone-barbican-command
>
> Link: https://openstack.nimeyo.com/62868/?show=62868#q62868
> From: marif82 
>
> Hi Asha,
>
> I am also getting the same error when I am executing the curl command to
> create secret.
>
> bash-4.2$ curl -X POST -H 'content-type:application/json' -H
> 'X-Project-Id:12345' -d '{"payload": "my-secret-here","payload*content*type":
> "text/plain"}' http://localhost:9311/v1/secrets
> Authentication requiredbash-4.2$
>
> Can you please help me how you have solved this problem. I am using the
> safenet HSM for MKEK and HMAC and it generated successfully on HSM
> partition.
>
> Please help me to resolve this issue.
>
> Thanks & Regards,
> Arif
>
> __
> OpenStack Development Mailing 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] Gerrit permissions and Merge rights

[Armando M.]

On 21 October 2015 at 09:53, Kyle Mestery  wrote:

> On Wed, Oct 21, 2015 at 11:37 AM, Armando M.  wrote:
>
>>
>>
>> On 21 October 2015 at 04:12, Gal Sagie  wrote:
>>
>>> Do we also want to consider Project Kuryr part of this?
>>>
>>
>> No, why would we?
>>
>>
> The reason to consider it is because Kuryr is a sub-project of Neutron,
> and they are doing their spec submissions following the Neutron guidelines.
> Adding the kuryr-core gerrit group to be on part with the *aas repos makes
> sense here. If other sub-projects (like L2FW, SFC, etc.) start doing spec
> reviews in the neutron-specs repository, then adding them makes sense too.
>

I don't believe this is the road we set ourselves on when we started the
decomp/stadium. We wanted a clear separation of concerns and I don't see
how going down this path is going to help us achieve that.

I don't see the grounds to have such an abrupt change in direction right
now, especially for the level of work that that would imply and the
pressure that would put on the drivers team. Anyone is free to review and
contribute where it matters for them, and location should not prevent them
from doing so.


>
>
>> We already started sending Kuryr spec to the Neutron repository and I
>>> think it would make sense to manage it
>>> as part of Neutron spec process.
>>>
>>
>> No, unless what you are asking are changes to the core. Do you have a
>> reference for me to look at?
>>
>>
> See above, perhaps I answered this for you.
>

>
>>
>>> Any opinions on that?
>>>
>>> Gal.
>>>
>>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>>>
 Hi folks,

 During revision of the Neutron teams [1], we made clear that the
 neutron-specs repo is to be targeted by specs for all the Neutron projects
 (core + *-aas).

 For this reason I made sure that the neutron-specs-core team +2 right
 was extended to all the core teams.

 Be mindful, use your +2 rights with care: if you are core on a *-aas
 project, you should exercise that vote only for specs that pertain the
 project you're core of.

 If I could use this email as a reminder also of the core hierarchy and
 lieutenant system we switched to in Liberty ([3]): if you have been made
 core by a lieutenant of a sub-system, please use your +2/+A only within
 your area of comfort and reach out for help if in doubt.

 Reviews are always welcome though!

 Cheers,
 Armando

 [1] https://review.openstack.org/#/c/237180/
 [2] https://review.openstack.org/#/admin/groups/314,members
 [3]
 http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy


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


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

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Armando M.]

On 21 October 2015 at 09:52, Gal Sagie  wrote:

>
>
> On Wed, Oct 21, 2015 at 7:37 PM, Armando M.  wrote:
>
>>
>>
>> On 21 October 2015 at 04:12, Gal Sagie  wrote:
>>
>>> Do we also want to consider Project Kuryr part of this?
>>>
>>
>> No, why would we?
>>
>
> [Gal] Because Kuryr is a special project which was created in order to
> expose Neutron and its services to containers networking,
>  its mission (at least as defined right now) is to bridge the gaps
> between containers networking world and Neutron and for doing it
>  it already depends on the feature/spec process of Neutron.
>  That is why it make sense to me that just like the services
> projects, our spec approval process will be handled
>  as part of Neutron.
>

Kuryr is no more special than any other Neutron affiliated project, let's
be 100% clear about that: there is no double-standard here.

If you really think that Kuryr should be an integral part of the Neutron
project, then it should not exist, but fold within Neutron entirely. I
don't know the backstory of why this was spun off as a separate project in
the first place, but I think that there's some merits in having it as
standalone entity.

You are always welcome to reach out for feedback, after all the same people
may work/have an interest in multiple projects (fingers stuck in many pies
if you will :P), but going from there to what you're proposing is too big
of a leap which I find hard to justify.


>
>
>
>>
>>
>>> We already started sending Kuryr spec to the Neutron repository and I
>>> think it would make sense to manage it
>>> as part of Neutron spec process.
>>>
>>
>> No, unless what you are asking are changes to the core. Do you have a
>> reference for me to look at?
>>
>>
>   [Gal]   I dont understand what you mean "No" here, first this spec is
> sent to Mitaka:
>  https://review.openstack.org/#/c/213490/
>
> And as i mentioned above Kuryr spec process depends on Neutron
> (and the specs that are sent
> to Neutron core)
>

I'll review it and provide feedback. 'Depending on Neutron' means requiring
actual enhancement to the core platform that makes sense to be
tracked/discussed in Neutron. Everything else can be tracked independently:
this is the separation of concerns that we should strive for.


>
>
>>> Any opinions on that?
>>>
>>> Gal.
>>>
>>> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>>>
 Hi folks,

 During revision of the Neutron teams [1], we made clear that the
 neutron-specs repo is to be targeted by specs for all the Neutron projects
 (core + *-aas).

 For this reason I made sure that the neutron-specs-core team +2 right
 was extended to all the core teams.

 Be mindful, use your +2 rights with care: if you are core on a *-aas
 project, you should exercise that vote only for specs that pertain the
 project you're core of.

 If I could use this email as a reminder also of the core hierarchy and
 lieutenant system we switched to in Liberty ([3]): if you have been made
 core by a lieutenant of a sub-system, please use your +2/+A only within
 your area of comfort and reach out for help if in doubt.

 Reviews are always welcome though!

 Cheers,
 Armando

 [1] https://review.openstack.org/#/c/237180/
 [2] https://review.openstack.org/#/admin/groups/314,members
 [3]
 http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy


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


>>>
>>>
>>> --
>>> Best Regards ,
>>>
>>> The G.
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing 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][networking-sfc] no IRC project meeting for service function chaining project this week and next week

[Cathy Zhang]

Hi,

Since most of us are very busy with presentation preparation for the Summit, 
let's cancel this week's project meeting.
We will resume the meeting on 11/5.

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

Re: [openstack-dev] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Mike Scherbakov]

Can we do it in OpenStack Infra.. ?

On Wed, Oct 21, 2015 at 9:27 AM Aleksandra Fedorova 
wrote:

> Hi, Vitaly,
>
> there is nothing to prevent us from triggering test based on event in
> one project but checking out the code from another.
>
> So you can setup job triggered for patchset-created event in commit to
> fuel-web/ repo. Then in this job you checkout both: code from fuel-web
> and code from python-fuelclient in different subfolders, then run a
> test, get result and vote on patchset to fuel-web repository.
>
> python-fuelclient failures are not new indeed, and we have a bug [1]
> for 8.0 milestone to implement this kind of job. It will be much
> easier for CI team if we get initial implementation of the test so we
> can build a job on top. If you have some spare cycles - please
> participate, feel free to send a patch to jenkins-jobs repository
> directly [2] or comment on bug.
>
> [1] https://bugs.launchpad.net/fuel/+bug/1466897
> [2] https://review.fuel-infra.org/#/admin/projects/fuel-infra/jenkins-jobs
>
> On Wed, Oct 21, 2015 at 4:08 PM, Vitaly Kramskikh
>  wrote:
> > Hi,
> >
> > It's yet another time we broke fuelclient by merging a change in fuel-web
> > repo. Since we are considering moving Fuel UI to a separate repo, and we
> > need to run UI functional tests against changes in nailgun anyway, I
> think
> > we should start to change our CI so it could run tests from another repo
> > against changes in another repo.
> >
> > Can it be done?
> >
> > --
> > Vitaly Kramskikh,
> > Fuel UI Tech Lead,
> > 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
> >
>
>
> --
> Aleksandra Fedorova
> Fuel CI Engineer
> bookwar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] establishing release liaisons for mitaka

[Craig Vyvial]

Doug,

I updated the liaisons for Trove on the wiki page.

Thanks,
-Craig

On Wed, Oct 21, 2015 at 11:26 AM Doug Hellmann 
wrote:

> Excerpts from Lingxian Kong's message of 2015-10-21 16:42:32 +0800:
> > Hi, Doug,
> >
> > After conversition with Mistral PTL(Renat), I'm willing to be mistral
> > liaison to take participate in cross-project release effort on beharf
> > of mistral team, so please count me in.
>
> Great, thank you for volunteering!
>
> Please add your contact details to the wiki page [3], and make sure
> you have your email client configured so that you will see messages
> with the "[release]" topic tag.
>
> Doug
>
> [3]
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
>
> >
> > On Wed, Oct 14, 2015 at 11:25 PM, Doug Hellmann 
> wrote:
> > > As with the other cross-project teams, the release management team
> > > relies on liaisons from each project to be available for coordination
> of
> > > work across all teams. It's the start of a new cycle, so it's time to
> > > find those liaison volunteers.
> > >
> > > We are working on updating the release documentation as part of the
> > > Project Team Guide. Release liaison responsibilities are documented in
> > > [0], and we will update that page with more details over time.
> > >
> > > In the past we have defaulted to having the PTL act as liaison if no
> > > alternate is specified, and we will continue to do that during Mitaka.
> > > If you plan to delegate release work to a liaison, especially for
> > > submitting release requests, please update the wiki [1] to provide
> their
> > > contact information. If you plan to serve as your team's liaison,
> please
> > > add your contact details to the page.
> > >
> > > Thanks,
> > > Doug
> > >
> > > [0]
> http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons
> > > [1]
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
> > >
> > >
> __
> > > OpenStack Development Mailing 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] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

[Mike Scherbakov]

We should fix it everyone. I don't think we need to be too heavy with the
process, so I'd just update a single bug vs creating so many bugs...

Fuel Infra team - please provide an estimate when script is going to be
ready (which adds people automatically to gerrit review).

Thanks,

On Wed, Oct 21, 2015 at 6:04 AM Simon Pasquier 
wrote:

> Mike, thanks for the clarification!
> I've filed a bug against fuel-qa [0] and submitted a patch [1]. Note that
> after a quick look, many Fuel projects have the same issue with the format
> of the MAINTAINERS file. Do you think we need one bug per project or do we
> piggy-back on the fuel-qa bug?
> BR,
> Simon
> [0] https://bugs.launchpad.net/fuel/+bug/1508449
> [1] https://review.openstack.org/#/c/238039/
>
> On Wed, Oct 21, 2015 at 8:11 AM, Mike Scherbakov  > wrote:
>
>> Nastya,
>> according to the template I provided initially [1] format in fuel-qa is
>> invalid. I've requested to support only one format [2].
>> File must always have a folder. If you want to cover the whole repo, then
>> the right structure would be
>>
>> maintainers:
>>
>>
>> - ./:
>>
>> - name:   ...
>>
>>   email:  ...
>>
>>   IRC:...
>> e.g. you'd just refer to the current folder, which should be root of the
>> repo by default.
>> Simon is asking a valid request: if you add his folder in the file, he
>> will be always added to the review request by script, once it's
>> implemented. Only in the case when contribution is made to his particular
>> area of responsibility.
>>
>> [1] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
>> [2] https://bugs.launchpad.net/fuel/+bug/1497655
>>
>> On Tue, Oct 20, 2015 at 11:03 PM Anastasia Urlapova <
>> aurlap...@mirantis.com> wrote:
>>
>>> Simon,
>>> structure of fuel-web repo is much more complex than fuel-qa, ~ 50
>>> active contributors work with fuel-web.
>>> There is the functionality of the different Fuel domains and each
>>> requires its own expertise, so maintenance is divided by folders.
>>> In case of fuel-qa maintainers are doing review for whole repository,
>>> structure of file[0] is correct.
>>>
>>>
>>> Nastya.
>>> [0] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>>>
>>> On Wed, Oct 21, 2015 at 2:15 AM, Mike Scherbakov <
>>> mscherba...@mirantis.com> wrote:
>>>
 Simon,
 I believe that it's a mistake in fuel-qa. Valid structure is in
 fuel-web. Please fix the one in fuel-qa.

 I'm also looking forward for automated adding of people to review
 requests based on this file. Here is the task to track it:
 https://bugs.launchpad.net/fuel/+bug/1497655

 On Tue, Oct 20, 2015 at 2:10 AM Simon Pasquier 
 wrote:

> Thanks for the reply, Andrew! I must admit that I haven't read
> thoroughly the specification on the new team structure [1]. IIUC plugin
> developers should be added to the MAINTAINERS file of fuel-qa for the
> directories that concern their plugins. If I take LMA as an example, this
> would be:
> fuelweb_test/tests/plugins/plugin_elasticsearch
> fuelweb_test/tests/plugins/plugin_lma_collector
> fuelweb_test/tests/plugins/plugin_lma_infra_alerting
>
> Is that right?
>
> I can submit a change to fuel-qa for adding the LMA team to the
> MAINTAINERS file but I can't figure out the structure of the YAML data:
> fuel-web/MAINTAINERS [2] is organized as "{directory1: [maintainer1,
> maintainer2, ...], directory2: [...], ...}" while for fuel-qa [3] (and
> other Fuel projects), it's "[maintainer1, maintainer2, ...]".
>
> BR,
> Simon
>
> [1]
> http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
> [2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
> [3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>
>
> On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward 
> wrote:
>
>> We have already discussed this to be a result of describing data
>> driven testing, untill this spec is completed there is little sense to
>> remove all of these since fuel-qa is 100% required to operate this way. 
>> In
>> the interim we should just specify the appropriate SME with the 
>> MAINTAINERS
>> file.
>>
>> On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>>
>>> Tests should be in plugin
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier <
>>> spasqu...@mirantis.com> wrote:
>>>
 Hello Alexey,

 On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin <
 aela...@mirantis.com> wrote:

> Hello Simon!
>
> We are going to remove plugins' functional tests from fuel-qa

[openstack-dev] [cinder] meeting place for event Monday night in Tokyo ...

[Jay S. Bryant]

All,

As has been our custom during previous summits, the Cinder team would 
will be getting together for dinner and drinks on Monday night (11/26) 
at the Tokyo Summit.


Not sure where the evening will take us, but we are planning to meet by 
registration at the Convention Center.  Looking at the map, if I am 
reading it properly, in front of the Huawei Community Lounge on the 
first floor looks like a good place to meet that is right near 
registration.  So, lets go for that.  :-)


We will be meeting at 7:30pm and then decide where we want to go from there.

Look forward to seeing those who can make it!

Jay


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

[openstack-dev] [ironic] Ironic design summit schedule

[Wan-yen Hsu]

Hi Jim,

   My techtalk is supposed to finish by 2:45pm.  However, techtalk schedule
is not as well monitored  as formal sessions so it could get delayed.
That's why I was exploring whether the group management session can be
switched to Thursday.  Thanks!

Wanyen

>>* Hi Jim, *> >* Is it possible to switch Group management session to
Thursday? I *
*>*>* have a techtalk at 2:30pm on Wednesday and it makes it very tight for
me *>* >>and Shiv to attend the group management at 2:50 pm. Since Shiv and
myself *>>* are the proposer for the group management session, we want to
be able to *>* attend this discussion. Thanks! *

>Your talk is 2:00-2:40, correct? The reason I scheduled it at 2:50 is
>because of this talk. The only other place I could put it is Thursday at
>11:00, however some operators expressed more interest in the driver API
>session, and they have Wednesday sessions going on.

>I'd prefer if you could just walk quickly (run?) between these two - if
>you think that is impossible I may be able to switch them. Let me know. :)

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

Re: [openstack-dev] [cinder] meeting place for event Monday night in Tokyo ...

[Anita Kuno]

On 10/21/2015 05:04 PM, Jay S. Bryant wrote:
> 
> 
> On 10/21/2015 04:00 PM, Anita Kuno wrote:
>> On 10/21/2015 04:54 PM, Jay S. Bryant wrote:
>>> All,
>>>
>>> As has been our custom during previous summits, the Cinder team would
>>> will be getting together for dinner and drinks on Monday night (11/26)
>>> at the Tokyo Summit.
>>>
>>> Not sure where the evening will take us, but we are planning to meet by
>>> registration at the Convention Center.  Looking at the map, if I am
>>> reading it properly, in front of the Huawei Community Lounge on the
>>> first floor looks like a good place to meet that is right near
>>> registration.  So, lets go for that.  :-)
>>>
>>> We will be meeting at 7:30pm and then decide where we want to go from
>>> there.
>>>
>>> Look forward to seeing those who can make it!
>>>
>>> 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
>> Do you need a list of folks or just wander by and go from there?
>>
>> Looking forward to seeing Cinder folk at summit!
>>
>> Thanks Jay,
>> Anita.
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Anita,
> 
> Good question.  Don't think we were planning on getting a list of
> people.  Just going to see
> who all is there at 7:30 and roll with it!

Understood.

> 
> Summits are best when we just see where the wind takes us.  ;-)

Agreed, I am planned out. At some point the wind with take me to Cinder
folks, if it is Monday so much the better!

Thanks Jay,
Anita.

> 
> Will be good to see you again as well!
> 
> Jay
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Trove] Mitaka Design Summit Sessions

[Craig Vyvial]

We've updated the Trove Sessions to include some great topics.

https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Trove
http://mitakadesignsummit.sched.org/overview/type/trove

Thanks to everyone involved and looking forward to seeing everyone next
week!

-Craig Vyvial
(cp16net)
__
OpenStack Development Mailing 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] meeting place for event Monday night in Tokyo ...

[Anita Kuno]

On 10/21/2015 04:54 PM, Jay S. Bryant wrote:
> All,
> 
> As has been our custom during previous summits, the Cinder team would
> will be getting together for dinner and drinks on Monday night (11/26)
> at the Tokyo Summit.
> 
> Not sure where the evening will take us, but we are planning to meet by
> registration at the Convention Center.  Looking at the map, if I am
> reading it properly, in front of the Huawei Community Lounge on the
> first floor looks like a good place to meet that is right near
> registration.  So, lets go for that.  :-)
> 
> We will be meeting at 7:30pm and then decide where we want to go from
> there.
> 
> Look forward to seeing those who can make it!
> 
> 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

Do you need a list of folks or just wander by and go from there?

Looking forward to seeing Cinder folk at summit!

Thanks Jay,
Anita.

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

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

[michael mccune]

On 10/21/2015 05:11 PM, Michael Xin wrote:

Rob and Michael:
Thanks for the update. We will probably not use any Openstack Logo.

Here is the first draft of the flyer:

http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf


Please send us your feedback.


+1, i like the look of this flyer. especially the flag logo thingie, 
nicely done!


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] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

[Sean McGinnis]

On Wed, Oct 21, 2015 at 01:58:46PM -0400, Davanum Srinivas wrote:
> Sean,
> 
> If you are using the GMR code from oslo-incubator, please switch over to
> the new oslo.service. I don't see any pending reviews.
> 
> Thanks,
> -- Dims

Thanks Dims. I remembered the initial patch from May that added it
directly, but now I see it was updated in June.

There is a devref doc that needs to be updated. Other projects using GMR
might want to check if any instructions were added to their projects
that may need to be updated with this information.

Thanks!
Sean

> 
> On Wed, Oct 21, 2015 at 1:29 PM, Sean McGinnis 
> wrote:
> 
> > On Wed, Oct 21, 2015 at 02:43:39PM +0200, Kashyap Chamarthy wrote:
> > > Background
> > > --
> > >
> > > Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
> > > mechanism that allows one to capture the current state of a Nova
> > > process/executable (e.g. `nova-compute`, `nova-api`, etc).
> > >
> > > The way to generate the error report is to supply the 'User-defined
> > > signal', SIGUSR1, when killing a Nova process.  E.g.
> > >
> > > $ kill -USR1 `pgrep nova-compute`
> > >
> > > which results in GMR being printed to your standard error ('stderr')
> > > stream, wherever it ends up being redirected to (e.g. to a corresponding
> > > Nova process-specific log file, otherwise, on systemd-enabled systems,
> > > to its journal).
> > >
> > >
> > > Change in Mitaka (and above)
> > > 
> > >
> > > From the upcoming Mitaka release onwards, the default expected UNIX
> > > signal to generate GMR has been changed[1] from USR1 to USR2 (another
> > > User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
> > > for its own purpose.
> > >
> > > So, to generate GMR, from Mitaka release:
> > >
> > > $ kill -USR2 `pgrep nova-compute`
> > >
> > > A corresponding Nova documentation change[2] has been submitted to
> > > reflect this new reality.
> >
> >
> > Do you know if anyone is working on updating all projects that GMR was
> > added to? Or should we each look at our own projects and make the
> > necessary changes?
> >
> >
> > >
> > >
> > > [1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
> > > Use SIGUSR2 instead of SIGUSR1
> > > [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
> > > instructions to generate GMR error reports
> > >
> > >
> > > [*] References
> > > --
> > >
> > > Related reading:
> > >
> > > - http://docs.openstack.org/developer/nova/gmr.html
> > > - http://docs.openstack.org/developer/oslo.reports/usage.html
> > > - https://wiki.openstack.org/wiki/GuruMeditationReport
> > > -
> > https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
> > >
> > > --
> > > /kashyap
> > >
> > >
> > __
> > > OpenStack Development Mailing 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
> >
> 
> 
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims

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


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

Re: [openstack-dev] [Nova] Migration state machine proposal.

[Joshua Harlow]

Question on some things seen in the below paste.

What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?

Why does it jump over 'reverting' or 'confirming'? Should it?

The other question is the difference between 'failed' and 'error' in the 
first diagram, any idea on why/how these are semantically different? The 
difference between 'done' and 'finished' are also in my mind 
semantically confusing.


Overall I'm very much inclined to have three state machines (one for 
each type), vs the mix-mash of all three into one state machine (which 
causes the confusion around states in the first diagram in that paste).


Josh

Tang Chen wrote:

Hi,

Please help to take a look at this problem. I was trying to raise it in
the spec discussion.
But since we don't need a spec on this problem, so I want to discuss it
here.
It is about what the new state machine will be.

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

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

Re: [openstack-dev] Custom Nova scheduler based on CPU queue length (Clint Byrum)

[Rahul Nair]

ctory2: [...], ...}" while for fuel-qa [3] (and
> >> other Fuel projects), it's "[maintainer1, maintainer2, ...]".
> >>
> >> BR,
> >> Simon
> >>
> >> [1]
> >>
> http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
> >> [2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
> >> [3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
> >>
> >>
> >> On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward <xar...@gmail.com>
> >> wrote:
> >>
> >>> We have already discussed this to be a result of describing data driven
> >>> testing, untill this spec is completed there is little sense to remove
> all
> >>> of these since fuel-qa is 100% required to operate this way. In the
> interim
> >>> we should just specify the appropriate SME with the MAINTAINERS file.
> >>>
> >>> On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <
> >>> sgolovat...@mirantis.com> wrote:
> >>>
> >>>> Tests should be in plugin
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Sergii Golovatiuk,
> >>>> Skype #golserge
> >>>> IRC #holser
> >>>>
> >>>> On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier <
> spasqu...@mirantis.com
> >>>> > wrote:
> >>>>
> >>>>> Hello Alexey,
> >>>>>
> >>>>> On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin <aela...@mirantis.com
> >
> >>>>> wrote:
> >>>>>
> >>>>>> Hello Simon!
> >>>>>>
> >>>>>> We are going to remove plugins' functional tests from fuel-qa
> because
> >>>>>> this tests don't use for our plugins CI process.
> >>>>>>
> >>>>>
> >>>>> And where are the existing tests going to be stored then?
> >>>>>
> >>>>> Thanks,
> >>>>> Simon
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> __
> >>>>>> OpenStack Development Mailing 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
> >>>>
> >>> --
> >>>
> >>> --
> >>>
> >>> Andrew Woodward
> >>>
> >>> Mirantis
> >>>
> >>> Fuel Community Ambassador
> >>>
> >>> Ceph Community
> >>>
> >>>
> >>>
> __
> >>> OpenStack Development Mailing 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
> >>
> > --
> > Mike Scherbakov
> > #mihgen
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/28009ffb/attachment-0001.html
> >
>
> --
>
> Message: 4
> Date: Wed, 21 Oct 2015 06:01:36 +
> From: Mike Scherbakov <mscherba...@mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Modularization activity POC
> Message-ID:
> 

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

[Clark, Robert Graham]

Wow, that looks amazing. 

It's pretty late my time so I'll take a closer look at the text tomorrow but 
the overall look and style is superb! Thank you for all the effort that's gone 
into this!

> -Original Message-
> From: Michael Xin [mailto:michael@rackspace.com]
> Sent: 21 October 2015 22:11
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: openstack-secur...@lists.openstack.org
> Subject: Re: [openstack-dev] [security] The first version of the Logo for 
> Openstack Security Project
> 
> Rob and Michael:
> Thanks for the update. We will probably not use any Openstack Logo.
> 
> Here is the first draft of the flyer:
> 
> http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf
> 
> 
> Please send us your feedback.
> 
> 
> Yours,
> Michael
> 
> 
> 
> 
> 
> On 10/21/15, 11:32 AM, "Clark, Robert Graham"  wrote:
> 
> >I had looped some people into a previous version of the thread but they've 
> >not replied yet.
> >
> >I think we ran into this problem before and got a firm "maybe, depending on 
> >what it is" from the powers-that-be.
> >
> >Perhaps we should look at a rough-draft alternative logo while we await a 
> >verdict?
> >
> >> -Original Message-
> >> From: michael mccune [mailto:m...@redhat.com]
> >> Sent: 21 October 2015 17:27
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [security] The first version of the Logo for 
> >> Openstack Security Project
> >>
> >> On 10/21/2015 03:54 AM, Michael Xin wrote:
> >> > Hi, guys:
> >> > Thanks for your help. We are designing a logo and a flyer for Openstack
> >> > Security Project. Rachel helped us with the task. Attached is her first
> >> > version of the logo. Please let us know your feedback.
> >> >
> >> > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png
> >> > Thanks and have a great day.
> >>
> >> hi Michael, thanks to Rachel for putting this together. i like the
> >> general concept of the openstack logo as a lock. i think the "lock
> >> parts" could have a little more depth on them.
> >>
> >> you had asked in irc about usage of the openstack logo, i'm not sure.
> >> but this page, https://www.openstack.org/brand/openstack-logo/ , seems
> >> to indicate that the usage is pretty limited. in specific, this section
> >> "You agree that you will not (i) alter or modify the OpenStack Logo as
> >> provided by the OpenStack Foundation; " seems to indicate that we may
> >> not be able to use the logo like this. we should probably ask someone
> >> from the foundation.
> >>
> >> all in all though, a nice effort. many thanks =)
> >>
> >> mike
> >>
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >__
> >OpenStack Development Mailing 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] [fuel] Tests and feedback needed: Fuel ISO with Liberty support

[Dmitry Borodaenko]

All,

In case you've missed the announcement from Alexandra [0], Fuel now
supports OpenStack Liberty, and the nightly ISO images [1] are passing
our Build Verification Test [2].

[0] http://lists.openstack.org/pipermail/openstack-dev/2015-October/077309.html
[1] https://ci.fuel-infra.org/
[2] https://ci.fuel-infra.org/job/8.0.fuel_community.ubuntu.bvt_2/

This means that Fuel can deploy an HA/Neutron/Ceph configuration with 3
controllers and 3 computes/OSDs, and the OSTF health check of the
deployed Liberty environment (testing basic operations like launching
VMs and attaching volumes work) is reporting success.

If you're interested in Fuel and plan to deploy OpenStack Liberty,
please have a look, try it out, and give us feedback. It's not yet
production ready and we'll still be working on new features until
December [4], which means that it's not too late to ask for changes :)

[4] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule

If you find a problem, please don't hesitate to report it on IRC (#fuel)
or in Launchpad [5].

[5] https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Test_and_report_bugs

Thank you,

-- 
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] meeting place for event Monday night in Tokyo ...

[Jay S. Bryant]

On 10/21/2015 04:00 PM, Anita Kuno wrote:

On 10/21/2015 04:54 PM, Jay S. Bryant wrote:

All,

As has been our custom during previous summits, the Cinder team would
will be getting together for dinner and drinks on Monday night (11/26)
at the Tokyo Summit.

Not sure where the evening will take us, but we are planning to meet by
registration at the Convention Center.  Looking at the map, if I am
reading it properly, in front of the Huawei Community Lounge on the
first floor looks like a good place to meet that is right near
registration.  So, lets go for that.  :-)

We will be meeting at 7:30pm and then decide where we want to go from
there.

Look forward to seeing those who can make it!

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

Do you need a list of folks or just wander by and go from there?

Looking forward to seeing Cinder folk at summit!

Thanks Jay,
Anita.

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

Anita,

Good question.  Don't think we were planning on getting a list of 
people.  Just going to see

who all is there at 7:30 and roll with it!

Summits are best when we just see where the wind takes us.  ;-)

Will be good to see you again as well!

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] [security] The first version of the Logo for Openstack Security Project

[Michael Xin]

Rob and Michael:
Thanks for the update. We will probably not use any Openstack Logo. 

Here is the first draft of the flyer:

http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf


Please send us your feedback. 


Yours,
Michael 





On 10/21/15, 11:32 AM, "Clark, Robert Graham"  wrote:

>I had looped some people into a previous version of the thread but they've not 
>replied yet.
>
>I think we ran into this problem before and got a firm "maybe, depending on 
>what it is" from the powers-that-be.
>
>Perhaps we should look at a rough-draft alternative logo while we await a 
>verdict?
>
>> -Original Message-
>> From: michael mccune [mailto:m...@redhat.com]
>> Sent: 21 October 2015 17:27
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [security] The first version of the Logo for 
>> Openstack Security Project
>> 
>> On 10/21/2015 03:54 AM, Michael Xin wrote:
>> > Hi, guys:
>> > Thanks for your help. We are designing a logo and a flyer for Openstack
>> > Security Project. Rachel helped us with the task. Attached is her first
>> > version of the logo. Please let us know your feedback.
>> >
>> > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png
>> > Thanks and have a great day.
>> 
>> hi Michael, thanks to Rachel for putting this together. i like the
>> general concept of the openstack logo as a lock. i think the "lock
>> parts" could have a little more depth on them.
>> 
>> you had asked in irc about usage of the openstack logo, i'm not sure.
>> but this page, https://www.openstack.org/brand/openstack-logo/ , seems
>> to indicate that the usage is pretty limited. in specific, this section
>> "You agree that you will not (i) alter or modify the OpenStack Logo as
>> provided by the OpenStack Foundation; " seems to indicate that we may
>> not be able to use the logo like this. we should probably ask someone
>> from the foundation.
>> 
>> all in all though, a nice effort. many thanks =)
>> 
>> mike
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Integrating kollacli as python-kollaclient

[Steven Dake (stdake)]

Hello Folks,


Oracle has developed a CLI tool for managing OpenStack Kolla clusters.  Several 
months ago at our midcycle, the topic was brought up an I suggested to go ahead 
and get started on the work.  We clearly didn't spend enough time discussing 
how it should be integrated into the code base or developed or even what its 
features should be, and that is my error.


What ended up happening is sort of a code dump, which is not ideal, but I can 
only work so many 20 hour days ;)  I didn't believe our community had the 
bandwidth to deal with integrating a CLI directly into the tree while we were 
focused on our major objective of implementing Ansible deployment of OpenStack 
in Docker containers.  Possibly the wrong call, but it is what it is and it is 
my error, not Oracles.


The code can be cloned from:

git clone git://oss.oracle.com/git/openstack-kollacli.git


The code as is is very high quality but will likely need to go through alot of 
refactoring to ReST-ify it.  There are two major authors of the code, Borne 
Mace and Steve Noyes.


I'd like a majority vote from the core team as to whether we should add this 
repository to our list of governed repositories in the OpenStack Kolla 
governance repository here:


https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1509


Consider this email a +1 vote from me.


A completely separate email thread and decision will be made by the community 
about core team membership changes to handle maintenance of the code.  Assuming 
this code is voted into Kolla's governance, I plan to propose Borne as a core 
reviewer, which will be open to core team vote as a separate act with our 3 +1 
votes no vetos within 1 week period.  We will address that assuming a majority 
vote of the code merge wins.  Steve can follow the normal processes for joining 
the core team if he wishes (reviewing patches) - clearly his code contributions 
are there.  Borne already does some reviews, and although he isn't a top 
reviewer, he does have some contribution in this area making it into the top 10 
for the Liberty cycle.



Kolla CLI Features:

  *   dynamic ansible inventory manipulation via the host, group and service 
commands
  *   ssh key push via the host setup command
  *   ssh key validation via the host check command
  *   ansible deployment via the deploy command
  *   property viewing and modification with the property list, set and clear 
commands
  *   cleanup of docker containers on a single, multiple or all hosts via the 
host destroy command
  *   debug data collection via the dump command
  *   configuration of openstack passwords via the password command
  *   Lines of python = 2700
  *   Lines of  test case code =  1800
  *   ~ 200 commits

__
OpenStack Development Mailing 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] Driver documentation in Ironic

[Wan-yen Hsu]

As mentioned in the weekly IRC, 3rd-party vendor drivers are ranked lower
priority and therefore their code tend to merge at the late cycle of a
release.   Therefore,  it leads little time for driver author to submit
document and for upstream to review and approve the document.  So, as the
result, the 3r-party driver document could miss the release.  I don't think
the suggestion of code+document  submission and review will help
either.  IMO it will slow down review process as reviewers will need to
review documents for every feature comparing to one single document review
after all features are landed.  Hence I am concerned that it will slow down
the review process and make landing vendor's driver code even harder unless
upstream is willing to raise priority for vendor driver specs and code.
 Also,  some features are inter-related and can introduce document
inter-dependency if feature and documentation are bundled.   Moreover,
currently it is very difficult (if possible) to modify document after it
got merged into a stable tree.   Like defect in code, defects in document
exist.  For instance, some important configuration steps or pre-requisites
may be missing in the document.  Sometimes new firmware version has impact
on vendor's drivers and it will require changes in driver's pre-requisites
or configuration in order to work with the new firmware versions.  These
will require document changes in the stable branch.  Therefore, there is a
need for vendor driver author to make changes in stable branch to fix
document defects, document known firmware issues and resolutions, and
update information about supported firmware versions and hardware.   IMO,
Ramesh's option 2  & 3 will provide this kind of flexibility.  Option1 will
help driver document to land in time tor a release but won't enable changes
to the stable branch unless upstream allow driver authors to
self-approve document changes in the stable branch.It would be my
preference, if PTL and upstream can work with infra to allow driver authors
to self-approve changes to the stable branch.   I am sincerely asking  for
help.  Any upstream effort to allow driver's document change in stable
branch and help driver document to land in new release in time will be very
much appreciated.
Thanks!

On Thu, Oct 15, 2015 at 09:23:18PM +0530, Ramakrishnan G wrote:
>* Hi All, *> >* This mail is related to driver-specific documentation in
Ironic. *> >* First a bit of context. I work on iLO drivers in Ironic. Our
team would *>* like to document both Ironic driver related stuff (which is
related to *>* Ironic) and hardware related stuff like tested platforms,
firmware *>* information, firmware issues, etc (which is not related to
Ironic) in the *>* documentation. Today we keep it at two places - ironic
related one in *>* ironic tree and (ironic + non-ironic) related one in
wiki. It's hard for *>* both people who work on documentation and people
who read this *>* documentation to update/refer information in two places.
Hence we decided *>* to raise the review [0] to move the content completely
to wiki. It got *>* mixed response. While some people are okay with it, but
some others *>* (including our ptl :)) feel it's worth putting it in-tree
and try to *>* address the problems. *> >* So what all are the problems ? *>*
1) Ability to update the driver documentation not-related to Ironic easily *
>* without waiting. *>* 2) To save some core reviewers time who might not
be familiar with the *>* hardware. *> >* To solve the actual problem of
updating the documentation easily while *>* keeping it in-tree, I checked
with infra folks if a subset of a repository *>* can be +2ed/+Aed by
another group. They confirmed it's not possible *>* (unless there was a
communication gap in that conversation, folks can *>* correct me if I am
wrong). *> >* The following are the options that I can think of to address
this: *> >* 1) Easy approvals for patches solely related to driver
documentation. Once *>* the driver team feels the documentation is ready,
it can be +Aed by a core *>* team member skipping the normal process of
review. Of course, fixing any *>* comments that come by, but not waiting
for the normal rule of 2x+2s. *> >* 2) A separate repository for driver
documentation controller by driver *>* developers (a bad idea ??) *> >* 3)
Allow to push driver documentation to wiki for those who wish to. *> >*
Thoughts ??? *
We talked about this in our IRC meeting as well, and there isn't really
a good answer for "allow driver authors to merge their own docs ASAP".

I'd like to see some examples of docs patches that: 1) took too long to
merge, and 2) what problems that caused.

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

[openstack-dev] [Neutron][Nova] Trunk port feature (VLAN aware VMs)

[Ildikó Váncsa]

Hi Folks,

During Liberty we started the implementation of the VLAN aware VMs blueprint 
(https://review.openstack.org/#/c/94612/). We had quite a good progress, 
although we could use some extra hands on Neutron side and some thoughts on the 
Nova-Neutron interaction aspect of the feature.

The status of the code can be checked here:
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/vlan-aware-vms,n,z
https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:master+topic:bp/vlan-aware-vms,n,z
https://review.openstack.org/#/c/213120/ 
The spec proposed for Nova can be found here:
https://review.openstack.org/#/c/213644/


We also added a note to the corresponding cross-project session to discuss 
further the impacts of this feature on Nova:
https://mitakadesignsummit.sched.org/event/c2292316e85e922a9a649191ad1e0160#.VigTqpeLJ4M
https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-integration 

If you are interested in this feature and would like to help out please let me 
know. If you will be in Tokyo, we can catch up during/after the cross-project 
session or set up a separate discussion to move forward and speed up the 
feature implementation.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

__
OpenStack Development Mailing 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][Nova] Trunk port feature (VLAN aware VMs)

[Armando M.]

On 21 October 2015 at 15:40, Ildikó Váncsa 
wrote:

> Hi Folks,
>
> During Liberty we started the implementation of the VLAN aware VMs
> blueprint (https://review.openstack.org/#/c/94612/). We had quite a good
> progress, although we could use some extra hands on Neutron side and some
> thoughts on the Nova-Neutron interaction aspect of the feature.
>
> The status of the code can be checked here:
>
> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/vlan-aware-vms,n,z
>
> https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:master+topic:bp/vlan-aware-vms,n,z
> https://review.openstack.org/#/c/213120/
> The spec proposed for Nova can be found here:
> https://review.openstack.org/#/c/213644/
>
>
> We also added a note to the corresponding cross-project session to discuss
> further the impacts of this feature on Nova:
>
> https://mitakadesignsummit.sched.org/event/c2292316e85e922a9a649191ad1e0160#.VigTqpeLJ4M
>
> https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-integration
>
> If you are interested in this feature and would like to help out please
> let me know. If you will be in Tokyo, we can catch up during/after the
> cross-project session or set up a separate discussion to move forward and
> speed up the feature implementation.
>

Hi,

Thanks for the email. We discussed blueprint [1] during the last IRC
meeting [2] and based on our latest blueprint procedures [3], Rossella has
volunteered to help you through the process. She is going to be the main
point of contact for anything related to the feature. We'll watch the
progress of the blueprint over the course of the cycle and the meeting
participation is encouraged to raise/discuss blockers.

HTH
Armando

[1] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
[2]
http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-10-20-14.00.log.html
[3]
http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements


> Thanks and Best Regards,
> Ildikó
> (IRC: ildikov)
>
> __
> OpenStack Development Mailing 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] {Blazar]{Nova] Tokyo meetup and next steps

[Ildikó Váncsa]

Hi,

The upcoming OpenStack Summit in Tokyo is a great opportunity to discuss open 
questions, like resource management and resource reservation.

The Promise project in OPNFV is working on to identify the use cases and find a 
solution to this missing piece. For further information about this project 
please check the wiki page: https://wiki.opnfv.org/promise. You can find 
further information about our use cases and plans here: 
http://artifacts.opnfv.org/promise/PromiseResourceManagement.pdf.

We are trying to find a solution that can be integrated with OpenStack, 
therefore our primary interest is Blazar and the Nova scheduler activities.
If any of you is interested in resource reservation and/or in Blazar please let 
me know so that we can set up a meeting for next week to discuss further the 
possible solutions and tasks.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

__
OpenStack Development Mailing 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] Logging sessions at the Tokyo summit -- Let's get serious!

[Rochelle Grober]

Hey operators and other users (and devs),

We've got a number of logging sessions scheduled for the Summit.

I'm collecting up information on the summit logging etherpad:  
https://etherpad.openstack.org/p/TYO-ops-logging
and it will get fleshed out a lot more during the flight;-)

Two goals of the sessions:  Get Error Codes spec into a condition the devs will 
accept it
Define the Logging in OpenStack document and get commitments from Ops folks to 
write the various sections.

I also want to discuss

* the recent acceptance of the request-ID spec and how we might want to 
influence the implementation for logging purposes

o   
http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html

* A network security and FW logging spec

o   https://review.openstack.org/#/c/203509/25  that also has a session in the 
design summit

* App agnostic logging parameters -- suggestions/advice/details for 
devs to consider for this.

o   
http://specs.openstack.org/openstack/oslo-specs/specs/kilo/app-agnostic-logging-parameters.html

* Info level standardization  -- what is good, what is bad, let's file 
bugs?

* Notifications - rules on what should be logged and what shouldn't

So, there is much too much to cover during the sessions, but we can pick the 
ones (or others) that are important to the attendees.  Please add what you 
think is important to the etherpad and come to the sessions.

Here are the sessions related to logging:

http://sched.co/4QeM
http://sched.co/49xh
http://sched.co/49yK
http://sched.co/4Fjf
These two are at the same time.  They should have the same people in at least 
part of them.  Maybe we should ask Oslo to join us after they address rootwrap 
and security
http://sched.co/4Nl5
http://sched.co/4QcR
http://sched.co/4S1C
http://sched.co/4Qbp (for writing the logging doc)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Ironic design summit schedule

[Jim Rollenhagen]

On Wed, Oct 21, 2015 at 02:24:08PM -0700, Wan-yen Hsu wrote:
> Hi Jim,
> 
>My techtalk is supposed to finish by 2:45pm.  However, techtalk schedule
> is not as well monitored  as formal sessions so it could get delayed.
> That's why I was exploring whether the group management session can be
> switched to Thursday.  Thanks!

I've switched the group management session with the driver API session.
Apologies to all for the late switch, and especially to ops who were
interested in the driver API session but have a conflict.

// jim

> 
> Wanyen
> 
> >>* Hi Jim, *> >* Is it possible to switch Group management session to
> Thursday? I *
> *>*>* have a techtalk at 2:30pm on Wednesday and it makes it very tight for
> me *>* >>and Shiv to attend the group management at 2:50 pm. Since Shiv and
> myself *>>* are the proposer for the group management session, we want to
> be able to *>* attend this discussion. Thanks! *
> 
> >Your talk is 2:00-2:40, correct? The reason I scheduled it at 2:50 is
> >because of this talk. The only other place I could put it is Thursday at
> >11:00, however some operators expressed more interest in the driver API
> >session, and they have Wednesday sessions going on.
> 
> >I'd prefer if you could just walk quickly (run?) between these two - if
> >you think that is impossible I may be able to switch them. Let me know. :)
> 
> // jim

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


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

[openstack-dev] [Senlin] Weekly meeting 10/27 cancelled, resuming after summit

[Qiming Teng]

Since most developers will attend the summit next week. The weekly
Senlin meeting next Tuesday will be skipped. We will resume on
11/03/2015. Right. We have more than 10 days to prepare an agenda,
:)

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

Best Wishes,
  Qiming


__
OpenStack Development Mailing 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] Migration state machine proposal.

[Tang Chen]

Hi Joshua,

On 10/22/2015 05:17 AM, Joshua Harlow wrote:

Question on some things seen in the below paste.

What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?


Let's take confirm as an example. Please refer to function confirm_resize().
Resize is one type of migration in the current implement. It needs some
confirmation, and should destroy the source VM after the migration finished.

I guess the 'finished' state means just the migration is finished. Not 
the whole

resize process. Just my guess.



Why does it jump over 'reverting' or 'confirming'? Should it?


Not sure. I think it is just the original design. The confirmation and 
destroying

of the source VM may take some time. So it needs a state to indicate the
operation is on going.



The other question is the difference between 'failed' and 'error' in 
the first diagram, any idea on why/how these are semantically 
different? The difference between 'done' and 'finished' are also in my 
mind semantically confusing.


Yes, they are confusing. That is also why I raised this question.

About 'failed' and 'error', by reading the code, I think 'error' means 
we caught
some known or defined exceptions, and we know how to handle it. 'failed' 
means

unexpected exceptions happened.

And 'finished', 'completed', 'done' are just used by different types of 
migrations.

I cannot tell the difference. So I suggest to unify them.



Overall I'm very much inclined to have three state machines (one for 
each type), vs the mix-mash of all three into one state machine (which 
causes the confusion around states in the first diagram in that paste).


That is an idea. But I would prefer to have one single state machine for 
migration,
because resize and evacuate are reusing migration. They can be in one 
state machine.


It would be very helpful if the designer of the migration process could 
share his idea.
But if it is just some code modified by many people many times, I think 
we should

remove the confusing states and give a easier, better state machine.

Thanks.



Josh

Tang Chen wrote:

Hi,

Please help to take a look at this problem. I was trying to raise it in
the spec discussion.
But since we don't need a spec on this problem, so I want to discuss it
here.
It is about what the new state machine will be.

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

Thanks.




__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

[Sean McGinnis]

On Wed, Oct 21, 2015 at 02:43:39PM +0200, Kashyap Chamarthy wrote:
> Background
> --
> 
> Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
> mechanism that allows one to capture the current state of a Nova
> process/executable (e.g. `nova-compute`, `nova-api`, etc).
> 
> The way to generate the error report is to supply the 'User-defined
> signal', SIGUSR1, when killing a Nova process.  E.g.
> 
> $ kill -USR1 `pgrep nova-compute`
> 
> which results in GMR being printed to your standard error ('stderr')
> stream, wherever it ends up being redirected to (e.g. to a corresponding
> Nova process-specific log file, otherwise, on systemd-enabled systems,
> to its journal).
> 
> 
> Change in Mitaka (and above)
> 
> 
> From the upcoming Mitaka release onwards, the default expected UNIX
> signal to generate GMR has been changed[1] from USR1 to USR2 (another
> User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
> for its own purpose.
> 
> So, to generate GMR, from Mitaka release:
> 
> $ kill -USR2 `pgrep nova-compute`
> 
> A corresponding Nova documentation change[2] has been submitted to
> reflect this new reality.


Do you know if anyone is working on updating all projects that GMR was
added to? Or should we each look at our own projects and make the
necessary changes?


> 
> 
> [1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
> Use SIGUSR2 instead of SIGUSR1 
> [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
> instructions to generate GMR error reports
> 
> 
> [*] References
> --
> 
> Related reading:
> 
> - http://docs.openstack.org/developer/nova/gmr.html
> - http://docs.openstack.org/developer/oslo.reports/usage.html
> - https://wiki.openstack.org/wiki/GuruMeditationReport
> - 
> https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
> 
> -- 
> /kashyap
> 
> __
> OpenStack Development Mailing 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] Congress social night

[Masahito MUROI]

Hi Congress folks,

Congress team plans to get-together on Wednesday night to be acquainted.

If you are interested, please fill out quick RSVP [1] by the end of the
week since I want to know a roughly estimated head count. If the number
is big, I'll book sports bar, Japanese style bar called "Izakaya" or
somewhere. The place and the time will depend on how many people want to
go since there is official events on Wednesday night.

1.
http://www.eventbrite.com/e/congress-team-dinner-in-tokyo-suumit-tickets-19199371838

best regard,
masahito

-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


__
OpenStack Development Mailing 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] Driver documentation in Ironic

[Jim Rollenhagen]

On Wed, Oct 21, 2015 at 03:30:05PM -0700, Wan-yen Hsu wrote:
> As mentioned in the weekly IRC, 3rd-party vendor drivers are ranked lower
> priority and therefore their code tend to merge at the late cycle of a
> release.   Therefore,  it leads little time for driver author to submit
> document and for upstream to review and approve the document.  So, as the
> result, the 3r-party driver document could miss the release.  I don't think
> the suggestion of code+document  submission and review will help
> either.  IMO it will slow down review process as reviewers will need to
> review documents for every feature comparing to one single document review
> after all features are landed.  Hence I am concerned that it will slow down
> the review process and make landing vendor's driver code even harder unless
> upstream is willing to raise priority for vendor driver specs and code.
>  Also,  some features are inter-related and can introduce document
> inter-dependency if feature and documentation are bundled.   Moreover,
> currently it is very difficult (if possible) to modify document after it
> got merged into a stable tree.   Like defect in code, defects in document
> exist.  For instance, some important configuration steps or pre-requisites
> may be missing in the document.  Sometimes new firmware version has impact
> on vendor's drivers and it will require changes in driver's pre-requisites
> or configuration in order to work with the new firmware versions.  These
> will require document changes in the stable branch.  Therefore, there is a
> need for vendor driver author to make changes in stable branch to fix
> document defects, document known firmware issues and resolutions, and
> update information about supported firmware versions and hardware.   IMO,
> Ramesh's option 2  & 3 will provide this kind of flexibility.  Option1 will
> help driver document to land in time tor a release but won't enable changes
> to the stable branch unless upstream allow driver authors to
> self-approve document changes in the stable branch.It would be my
> preference, if PTL and upstream can work with infra to allow driver authors
> to self-approve changes to the stable branch.   I am sincerely asking  for
> help.  Any upstream effort to allow driver's document change in stable
> branch and help driver document to land in new release in time will be very
> much appreciated.
> Thanks!

There are two separate issues here:

1) Driver docs are hard to land quickly. There are a number of proposals
for fixing this; none of them are ideal. I still want to see hard
evidence of this with links to Gerrit before I continue thinking about
this.

2) Driver docs may not be backported to stable branches. This is a
stable maintenance policy, not an Ironic policy. This problem is
somewhat unique to Ironic as most major projects have deployer docs in
the Ops guide repo, rather than in the code repo. I'm going to chat with
some docs/stable maintenance people in Tokyo about this, however I also
encourage you to do the same.

// jim

> 
> On Thu, Oct 15, 2015 at 09:23:18PM +0530, Ramakrishnan G wrote:
> >* Hi All, *> >* This mail is related to driver-specific documentation in
> Ironic. *> >* First a bit of context. I work on iLO drivers in Ironic. Our
> team would *>* like to document both Ironic driver related stuff (which is
> related to *>* Ironic) and hardware related stuff like tested platforms,
> firmware *>* information, firmware issues, etc (which is not related to
> Ironic) in the *>* documentation. Today we keep it at two places - ironic
> related one in *>* ironic tree and (ironic + non-ironic) related one in
> wiki. It's hard for *>* both people who work on documentation and people
> who read this *>* documentation to update/refer information in two places.
> Hence we decided *>* to raise the review [0] to move the content completely
> to wiki. It got *>* mixed response. While some people are okay with it, but
> some others *>* (including our ptl :)) feel it's worth putting it in-tree
> and try to *>* address the problems. *> >* So what all are the problems ? *>*
> 1) Ability to update the driver documentation not-related to Ironic easily *
> >* without waiting. *>* 2) To save some core reviewers time who might not
> be familiar with the *>* hardware. *> >* To solve the actual problem of
> updating the documentation easily while *>* keeping it in-tree, I checked
> with infra folks if a subset of a repository *>* can be +2ed/+Aed by
> another group. They confirmed it's not possible *>* (unless there was a
> communication gap in that conversation, folks can *>* correct me if I am
> wrong). *> >* The following are the options that I can think of to address
> this: *> >* 1) Easy approvals for patches solely related to driver
> documentation. Once *>* the driver team feels the documentation is ready,
> it can be +Aed by a core *>* team member skipping the normal process of
> review. Of course, fixing any *>* comments that come by, but 

[openstack-dev] [ironic] Next meeting is November 9

[Jim Rollenhagen]

Hi folks,

Since we'll all be at the summit next week, and presumably recovering
the following week, the next Ironic meeting will be on November 9, in
the usual place and time. See you there! :)

// jim

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

Re: [openstack-dev] [tc] [watcher] New project: Watcher

[gord chung]

hi,

seems like a neat idea, i had a few questions after watching the 
presentation from Vancouver.


- is Watcher streaming the data captured by Ceilometer or is it querying 
the Ceilometer db?
- is it utilising the Event data captured by Ceilometer or metric data? 
both?

- i notice there's a tsdb used by Watcher. what TSDB is supported?
- is alarming functionality provided by Aodh used or is the 'machine 
learning'+'orchestration' service meant to replace the functionality 
provided by Aodh+Heat?


one reason i'm asking is that Ceilometer has a section in wiki to list 
projects that leverage Ceilometer[1] so it's easy to track existing 
extensions. feel free to add Watcher there if you feel like it.


[1] https://wiki.openstack.org/wiki/Ceilometer#Ceilometer_Extensions

cheers,

On 21/10/2015 8:22 AM, Antoine CABOT wrote:

We are pleased to introduce Watcher, a new project in the OpenStack
ecosystem. We believe that a "resource optimization" service in an
OpenStack-based cloud is a crucial component that has been missing to
date and we have started working towards filling that gap.

OpenStack Watcher provides a flexible and scalable resource
optimization service for multi-tenant OpenStack-based clouds.
Watcher provides a complete optimization loop—including everything
from a metrics receiver, complex event processor and profiler,
optimization processor and an action plan applier. This provides a
robust framework to realize a wide range of cloud optimization goals,
including the reduction of data center operating costs, increased
system performance via intelligent virtual machine migration,
increased energy efficiency—and more!

Not only does Watcher provide several out-of-box optimization routines
for immediate value-add, but it also supports a pluggable
architecture by which custom optimization algorithms, data metrics and
data profilers can be developed and inserted into the Watcher framework.
Additionally, Watcher enables two different modes of execution—advise
mode (manual) or active mode (automatic), giving cloud administrators
the runtime flexibilities that their clouds require. Most importantly,
administrators of OpenStack-based clouds equipped with Watcher will
decrease their Total Cost of Ownership (TCO) by way of more efficient
use of their infrastructure and less “hands on” (read: manual)
administrator involvement to perform optimizations.

More information, including key use cases, architecture, etc., are
described on the project wiki [0].  Also feel free to browse some
source code [1, 2].

We meet weekly on Wednesdays at 16:00 UTC in the #openstack-meeting-3
IRC channel. You can also use #openstack-watcher to contact the team.

We hope to see you at our unconference session at the upcoming
OpenStack Summit in Tokyo and we are welcoming participation from the
community.  Let us know if you are interested in this topic and
join us in #openstack-watcher!

Regards,

Antoine Cabot (Watcher PTL) (acabot)
Susanne Balle (sballe)
Joe Cropper (jwcroppe)

[0] https://wiki.openstack.org/wiki/Watcher
[1] https://github.com/openstack/watcher
[2] https://github.com/openstack/python-watcherclient
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord


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

Re: [openstack-dev] [Fuel] Assigning VIPs on network config serialization

[Aleksey Kasatkin]

> Then we should close [1] as invalid, shoudn’t we?

AFAIC, no. We should check whether there is enough IPs for nodes /
VIPs with current network configuration.

I'd propose to add a handler for allocation of VIPs if VIPs can be useful
before deployment.
I'm not sure what are the cases.



Aleksey Kasatkin


On Wed, Oct 21, 2015 at 11:45 AM, Roman Prykhodchenko  wrote:

> Then we should close [1] as invalid, shoudn’t we?
>
> > 20 жовт. 2015 р. о 15:55 Igor Kalnitsky 
> написав(ла):
> >
> > Roman,
> >
> >> This behavior is actually described in [1]. Should we allocate
> >> VIPs on network check as well?
> >
> > No, we shouldn't. We should check whether it's enough IPs for nodes /
> > VIPs with current network configuration, but no more.
> >
> > - igor
> >
> > On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky 
> wrote:
> >> Andrew,
> >>
> >>> but the problem lies that VIP's need to already be allocated.
> >>
> >> Why? Fuel doesn't use them on this stage.
> >>
> >>
> >>> They need to be allocated on network update, or when a node role
> requiring
> >>> one is added to the environment.
> >>
> >> It looks like either you or me misunderstood something. AFAIK, node
> >> role itself has nothing in common with VIPs. It doesn't require any of
> >> them.
> >>
> >> Currently VIPs are requested by network roles, and network roles are
> >> the same for all nodes (except Network Templating case). Network roles
> >> are assigned on network, and if VIP is required for network role it
> >> will be allocated in the assigned network.
> >>
> >> So basically, it requires a huge effort to redesign our allocation
> >> system to achieve what you want, because:
> >>
> >> * Each time you reassign network role, the corresponding VIP should be
> >> re-allocated in the database either.
> >> * Each time you enable/disable plugins, the VIPs should be
> >> re-allocated, because plugins may export network roles.
> >> * Each time you add new node to cluster, the VIPs should be
> >> re-allocated, because with new node you simply may run out of free
> >> IPs. And, btw, should we assign IP on added nodes here? Or maybe
> >> postpone to serialization step?
> >>
> >> Well, Andrew, I believe we don't have enough resources to implement
> >> your proposal. Moreover, the proposed approach requires a lot of
> >> discussions and design meetings. And it definitely should be
> >> implemented in scope of some blueprint, not a bugfix.
> >>
> >>
> >>> Not knowing the address until serialization for deployment is too late.
> >>
> >> Once again - why? I agree, perhaps it would be useful, but there's no
> >> strict requirement on this and we should resolve our issues
> >> step-by-step. See my response above.
> >>
> >>
> >>> No, Again, this is too late.
> >>
> >> Too late for what?
> >>
> >>
> >> - Igor
> >>
> >> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko 
> wrote:
> >>> My concern here is that there is also a Network check feature that
> according to its name should check things like whether or not there’s
> enough IP addresses in all ranges in a network. The problem is that it may
> be run at any time, even when VIPs are not yet allocated. From a user-side
> the workflow may look a little wrong:
> >>>
> >>> 1. Check network => get "Everything is fine"
> >>> 2. Right after that press Apply Changes => get "Network configuration
> is bad"
> >>>
> >>> This behavior is actually described in [1]. Should we allocate VIPs on
> network check as well?
> >>>
> >>>
> >>> 1. https://bugs.launchpad.net/fuel/+bug/1487996
> >>>
> >>>
> >>> - romcheg
> >>>
> >>>
>  19 жовт. 2015 р. о 18:28 Igor Kalnitsky 
> написав(ла):
> 
>  Hi Roman,
> 
> > Not assign addresses to VIPs is a network configuration is being
> > serialized for API output.
> 
>  AFAIK, that's not truth. Fuel UI and OSTF relies only on *public* VIP.
>  So we can keep only *public* VIP, and do not assign / show others.
> 
> > Check number of IP addresses wherever it is possible to "spoil"
> network
> > configuration: when a role get’s assigned to a node, when network
> > changes or network templates are applied.
> 
>  It won't work that way. What if you enable plugin when all roles are
>  assigned? What if you change networks, and now it's not enough IPs? Or
>  what if enable plugin that requires 5 VIPs in public network by
>  default, and it's not enough. But by using network templates you
>  assign this netrole to management network?
> 
>  From what I can say the proposed approach requires to put checks
>  here-and-there around the code. Let's do not overcomplicate things
>  without real need.
> 
>  So let me share my thoughts regarding this issue.
> 
>  * We shouldn't *allocate* VIPs when we make GET request on network
>  configuration handler. It should return only *already 

Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11

[Markus Zoeller]

"Daniel P. Berrange"  wrote on 10/21/2015 11:29:50 
AM:

> From: "Daniel P. Berrange" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/21/2015 11:42 AM
> Subject: Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11
> 
> On Tue, Oct 13, 2015 at 05:08:29PM -0700, Zaro wrote:
> > Hello All,
> > 
> > The openstack-infra team would like to upgrade from our Gerrit 2.8 to
> > Gerrit 2.11.  We are proposing to do the upgrade shortly after the
> > Mitaka summit.  The main motivation behind the upgrade is to allow us
> > to take advantage of some of the new REST api, ssh commands, and
> > stream events features.  Also we wanted to stay closer to upstream so
> > it will be easier to pick up more recent features and fixes.
> 
> Looking at the release notes I see my most wanted new feature, keyword
> tagging of changes, is available
> 
> [quote]
> Hashtags.
> 
> Hashtags can be added to changes. The hashtags are stored in git notes 
and
> are indexed in the secondary index.
> 
> This feature requires the notedb to be enabled.
> [/quote]
> 
> It is listed as an experimental feature, but I'd really love to see this
> enabled if at all practical.
> 
> Regards,
> Daniel

+1

A mockup from the Gerrit folks: http://i.imgur.com/T1azkvk.png

Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [Heat] core team nomination

[Rabi Mishra]

- Original Message -
> Congrats Rabi and Peter :)
> 
> -Original Message-
> From: Sergey Kraynev [mailto:skray...@mirantis.com]
> Sent: Wednesday, October 21, 2015 12:57 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Heat] core team nomination
> 
> Rabi, Peter, my congradulations. You were elected by a unanimous vote :) I
> will add you to heat-core group. Enjoy and stay on this course ! :)

Thank you all. I'll try and maintain my current level of activity.

> 
> On 21 October 2015 at 09:45, Qiming Teng  wrote:
> > +1 to both.
> >
> > Qiming
> >
> > On Tue, Oct 20, 2015 at 04:38:12PM +0300, Sergey Kraynev wrote:
> >> I'd like to propose new candidates for heat core-team:
> >> Rabi Mishra
> >> Peter Razumovsky
> >>
> >> According statistic both candidate made a big effort in Heat as
> >> reviewers and as contributors [1][2].
> >> They were involved in Heat community work  during last several
> >> releases and showed good understanding of Heat code.
> >> I think, that they are ready to became core-reviewers.
> >>
> >> Heat-cores, please vote with +/- 1.
> >>
> >> [1] http://stackalytics.com/report/contribution/heat-group/180
> >> [2] http://stackalytics.com/?module=heat-group=person-day
> >> --
> >> Regards,
> >> Sergey.
> >>
> >> _
> >> _ OpenStack Development Mailing 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
> 
> 
> 
> --
> Regards,
> Sergey.
> 
> __
> OpenStack Development Mailing 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
> 

Regards,
Rabi

__
OpenStack Development Mailing 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] HenryG addition to the Neutron Drivers team

[Kyle Mestery]

On Wed, Oct 21, 2015 at 4:01 AM, Ihar Hrachyshka 
wrote:

>
> > On 21 Oct 2015, at 05:14, Armando M.  wrote:
> >
> > Hi folks,
> >
> > Henry has been instrumental in many areas of the projects and his crazy
> working hours makes even Kevin and I bow in awe.
> >
> > Jokes aside, I would like to announce HenryG as a new member of the
> Neutron Drivers team.
> >
> > Having a propension to attendance, and desire to review of RFEs puts you
> on the right foot to join the group, whose members are rotated regularly so
> that everyone is given the opportunity to grow, and no-one burns out.
> >
> > The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
> attend.
> >
> > Please, join me in welcome Henry to the team.
>
> Nice addition. :)
>
> Do we have criteria for neutron-drivers team members documented? Or is it
> a mere ‘regularly attending the meetings, be mindful and apply common
> sense’?
>
> Like everything in Neutron, we do in fact have documentation on this. You
can find it here [1]. I imagine it could be expanded a bit to include some
more information, but it's a good start nonetheless.

Thanks,
Kyle

[1]
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team

> Ihar
>
> __
> OpenStack Development Mailing 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] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

[Simon Pasquier]

Mike, thanks for the clarification!
I've filed a bug against fuel-qa [0] and submitted a patch [1]. Note that
after a quick look, many Fuel projects have the same issue with the format
of the MAINTAINERS file. Do you think we need one bug per project or do we
piggy-back on the fuel-qa bug?
BR,
Simon
[0] https://bugs.launchpad.net/fuel/+bug/1508449
[1] https://review.openstack.org/#/c/238039/

On Wed, Oct 21, 2015 at 8:11 AM, Mike Scherbakov 
wrote:

> Nastya,
> according to the template I provided initially [1] format in fuel-qa is
> invalid. I've requested to support only one format [2].
> File must always have a folder. If you want to cover the whole repo, then
> the right structure would be
>
> maintainers:
>
>
> - ./:
>
> - name:   ...
>
>   email:  ...
>
>   IRC:...
> e.g. you'd just refer to the current folder, which should be root of the
> repo by default.
> Simon is asking a valid request: if you add his folder in the file, he
> will be always added to the review request by script, once it's
> implemented. Only in the case when contribution is made to his particular
> area of responsibility.
>
> [1] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
> [2] https://bugs.launchpad.net/fuel/+bug/1497655
>
> On Tue, Oct 20, 2015 at 11:03 PM Anastasia Urlapova <
> aurlap...@mirantis.com> wrote:
>
>> Simon,
>> structure of fuel-web repo is much more complex than fuel-qa, ~ 50 active
>> contributors work with fuel-web.
>> There is the functionality of the different Fuel domains and each
>> requires its own expertise, so maintenance is divided by folders.
>> In case of fuel-qa maintainers are doing review for whole repository,
>> structure of file[0] is correct.
>>
>>
>> Nastya.
>> [0] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>>
>> On Wed, Oct 21, 2015 at 2:15 AM, Mike Scherbakov <
>> mscherba...@mirantis.com> wrote:
>>
>>> Simon,
>>> I believe that it's a mistake in fuel-qa. Valid structure is in
>>> fuel-web. Please fix the one in fuel-qa.
>>>
>>> I'm also looking forward for automated adding of people to review
>>> requests based on this file. Here is the task to track it:
>>> https://bugs.launchpad.net/fuel/+bug/1497655
>>>
>>> On Tue, Oct 20, 2015 at 2:10 AM Simon Pasquier 
>>> wrote:
>>>
 Thanks for the reply, Andrew! I must admit that I haven't read
 thoroughly the specification on the new team structure [1]. IIUC plugin
 developers should be added to the MAINTAINERS file of fuel-qa for the
 directories that concern their plugins. If I take LMA as an example, this
 would be:
 fuelweb_test/tests/plugins/plugin_elasticsearch
 fuelweb_test/tests/plugins/plugin_lma_collector
 fuelweb_test/tests/plugins/plugin_lma_infra_alerting

 Is that right?

 I can submit a change to fuel-qa for adding the LMA team to the
 MAINTAINERS file but I can't figure out the structure of the YAML data:
 fuel-web/MAINTAINERS [2] is organized as "{directory1: [maintainer1,
 maintainer2, ...], directory2: [...], ...}" while for fuel-qa [3] (and
 other Fuel projects), it's "[maintainer1, maintainer2, ...]".

 BR,
 Simon

 [1]
 http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
 [2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
 [3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS


 On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward 
 wrote:

> We have already discussed this to be a result of describing data
> driven testing, untill this spec is completed there is little sense to
> remove all of these since fuel-qa is 100% required to operate this way. In
> the interim we should just specify the appropriate SME with the 
> MAINTAINERS
> file.
>
> On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Tests should be in plugin
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier <
>> spasqu...@mirantis.com> wrote:
>>
>>> Hello Alexey,
>>>
>>> On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin >> > wrote:
>>>
 Hello Simon!

 We are going to remove plugins' functional tests from fuel-qa
 because this tests don't use for our plugins CI process.

>>>
>>> And where are the existing tests going to be stored then?
>>>
>>> Thanks,
>>> Simon
>>>
>>>


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

Re: [openstack-dev] [Neutron] Gerrit permissions and Merge rights

[Kyle Mestery]

On Wed, Oct 21, 2015 at 6:12 AM, Gal Sagie  wrote:

> Do we also want to consider Project Kuryr part of this?
> We already started sending Kuryr spec to the Neutron repository and I
> think it would make sense to manage it
> as part of Neutron spec process.
>
> Any opinions on that?
>
> I think this makes sense, and I'd be in favor of this.


> Gal.
>
> On Tue, Oct 20, 2015 at 11:10 PM, Armando M.  wrote:
>
>> Hi folks,
>>
>> During revision of the Neutron teams [1], we made clear that the
>> neutron-specs repo is to be targeted by specs for all the Neutron projects
>> (core + *-aas).
>>
>> For this reason I made sure that the neutron-specs-core team +2 right was
>> extended to all the core teams.
>>
>> Be mindful, use your +2 rights with care: if you are core on a *-aas
>> project, you should exercise that vote only for specs that pertain the
>> project you're core of.
>>
>> If I could use this email as a reminder also of the core hierarchy and
>> lieutenant system we switched to in Liberty ([3]): if you have been made
>> core by a lieutenant of a sub-system, please use your +2/+A only within
>> your area of comfort and reach out for help if in doubt.
>>
>> Reviews are always welcome though!
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/237180/
>> [2] https://review.openstack.org/#/admin/groups/314,members
>> [3]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing 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] HenryG addition to the Neutron Drivers team

[Vikram Choudhary]

Congratulations Henry!

On Wed, Oct 21, 2015 at 6:33 PM, Kyle Mestery  wrote:

> On Wed, Oct 21, 2015 at 4:01 AM, Ihar Hrachyshka 
> wrote:
>
>>
>> > On 21 Oct 2015, at 05:14, Armando M.  wrote:
>> >
>> > Hi folks,
>> >
>> > Henry has been instrumental in many areas of the projects and his crazy
>> working hours makes even Kevin and I bow in awe.
>> >
>> > Jokes aside, I would like to announce HenryG as a new member of the
>> Neutron Drivers team.
>> >
>> > Having a propension to attendance, and desire to review of RFEs puts
>> you on the right foot to join the group, whose members are rotated
>> regularly so that everyone is given the opportunity to grow, and no-one
>> burns out.
>> >
>> > The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
>> attend.
>> >
>> > Please, join me in welcome Henry to the team.
>>
>> Nice addition. :)
>>
>> Do we have criteria for neutron-drivers team members documented? Or is it
>> a mere ‘regularly attending the meetings, be mindful and apply common
>> sense’?
>>
>> Like everything in Neutron, we do in fact have documentation on this. You
> can find it here [1]. I imagine it could be expanded a bit to include some
> more information, but it's a good start nonetheless.
>
> Thanks,
> Kyle
>
> [1]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
>
>> Ihar
>>
>> __
>> OpenStack Development Mailing 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] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo

[Vitaly Kramskikh]

Hi,

It's yet another time we broke fuelclient by merging a change
 in fuel-web repo. Since we are
considering moving Fuel UI to a separate repo, and we need to run UI
functional tests against changes in nailgun anyway, I think we should start
to change our CI so it could run tests from another repo against changes in
another repo.

Can it be done?

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
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

[openstack-dev] [Nova] Scheduler based on CPU queue length

[Rahul Nair]

Hi All,

I am fairly new to the OpenStack community and is trying to create a custom
scheduler for Nova. A scheduler based on CPU queue length of the physical
hosts. Kindly apologize if there are any inaccuracies in my statements.

As I understand a weigher for the filter scheduler that weighs filtered
host machines based on, 'cpu.percent' can be configured to prioritize the
hosts based on CPU percentage, but there are only limited options when it
comes to filtering of machines in the first place, that too using the CPU
queue length.

Also, I understand that IBM has its platform resource scheduler that can be
used to build custom plugins to get user defined metrics, is there a
similar way in pure Openstack which can be used to get the CPU queue length.

As of now, I am thinking of writing a custom script to be kept in all
compute nodes to retrieve the CPU queue length and send it to the Nova
controller, is this the way to go, or is there a defined approach that I
can follow to implement a scheduler that uses CPU queue length to filter
physical machines.

Any pointers on this would be really helpful.

Regards,
Rahul U Nair
__
OpenStack Development Mailing 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][sriov] SRIOV-VM could not work well with normal VM

[Alexander Duyck]

I assume by Intel cards you mean something that is running ixgbe?  If so 
and you are trying to use SR-IOV with OVS and VLANs running on top of 
the PF it will fail. The issue is that OVS requires the ability to place 
the PF in promiscuous mode to support VLAN trunking, and ixgbe driver 
prevents that when SR-IOV is enabled.


The "bridge fdb add" approach mentioned should work as long as ixgbe PF 
is used on a flat network.


- Alex

On 10/19/2015 07:33 PM, yujie wrote:

Hi Moshe Levi,
   Sorry for replying to this message after so long time. The testing 
environment was unavailable before.
   I use Intel cards, but could only tested base kilo and vlan. Could 
it work?


在 2015/9/22 13:24, Moshe Levi 写道:

Hi Yujie,

There is a patch https://review.openstack.org/#/c/198736/ which I 
wrote to add the mac of the normal instance to
the SR-IOV embedded switch so that the packet will go to the PF 
instead of going to the wire.
This is done by using bridge tool with the command "bridge fdb add 
 dev "


I was able to test it on Mellanox ConnectX3  card with both vlan and 
flat network and it worked fine.
I wasn't able to test it on any of the Intel cards, but I was told 
the it only working on flat network, in vlan network the Intel card 
is dropping the tagged packets and they are not go up to the VF.


What NIC are you using? Can you try using "bridge fdb add  dev 
" where  is the mac of the normal vm and  
is the PF

and see if  that resolve the issue.
Also can you check it with  flat and vlan networks.


-Original Message-
From: yujie [mailto:judy_yu...@126.com]
Sent: Tuesday, September 22, 2015 6:28 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][sriov] SRIOV-VM could not work 
well with normal VM


Hi all,
I am using neutron kilo without dvr to create sriov instance VM-A,it 
works well and could connect to its gateway fine.
But when I let the normal instance VM-B which in the same 
compute-node with VM-A ping its gateway, it failed. I capture the 
packet on the network-node, find the gateway already reply the 
ARP-reply message to VM-B. But compute-node which VM-B lives could 
not send the package to VM-B.

If delete VM-A and set : echo 0 >
/sys/class/enp5s0f0/device/sriov_numvfs, the problem solved.

Is it a same question with the bug: SR-IOV port doesn't reach OVS 
port on same compute node ?

https://bugs.launchpad.net/neutron/+bug/1492228
Any suggestions will be grateful.

Thanks,
Yujie


__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [api][ironic] some questions about tags

[Tan, Lin]

Hi guys,

Ironic is implementing the tags stuff:
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/nodes-tagging,n,z

And this work is follow the guidelines of API Workgroup:
http://specs.openstack.org/openstack/api-wg/guidelines/tags.html

But I have two doubts about the guideline:
1. Can we support partial update the Tag List using PATCH. I see there is an 
option to add/delete individual tag, but it is still using PUT. What's the 
disadvantage here for PATCH?

2. Can we update the tag as well? For example, in Gmail we can rename the label 
if necessary, which is much more friendly to me. But currently, this is not 
support from the guide. The only way to support this is cached the tags's 
entities and retag them in python client, I don't think it's a good way.
  
Best Regards,

Tan


__
OpenStack Development Mailing 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] [Solum] No meeting on October 27, 2015

[Devdatta Kulkarni]

Hi team,

In this week's IRC meeting we decided to cancel next week's meeting (on October 
27, 2015)
due to Tokyo summit. We will convene again on November 3.

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

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Matt Fischer]

I thought we had code in other places that split out stderr and only logged
it if there was an actual error but I cannot find the reference now. I
think that matches the original proposal. Not sure I like idea #3.

On Wed, Oct 21, 2015 at 9:21 AM, Stanislaw Bogatkin 
wrote:

> I spoken with Sergii about this and prepared a patch for get rid of
> SecurityWarning [0] - it was easy. But we can't get rid from 
> InsecurePlatformWarning
> so easy way. I see next options:
> 1. Update python version as [1] said - should be hard task
> 2. Downgrade urllib version to one without such warning - is a bad idea,
> as for me
> 3. Rewrite code to use non-standard ssl python module (pyOpenSSL, for
> example) - may be a massive task
> 4. Use something like 2>/dev/null to don't show stderr when call the
> command - doesn't looks good, cause problem can be seen on other places (I
> saw similar problems with keystone provider, for example)
> 5. Rewrite code to split stderr/stdout, as Sergey proposed - is a most
> reasonable idea, as for me.
>
> [0] https://review.openstack.org/#/c/237379
> [1]
> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
>
>
> On Wed, Oct 21, 2015 at 10:02 AM, Sergey Vasilenko <
> svasile...@mirantis.com> wrote:
>
>> Hi, guys!
>>
>> Now I observe potential-dangerous situation in the providers of
>> puppet-neutron module. I want share details, because not only
>> puppet-neutron module may be broken by warnings from Openstack CLI
>> utilities.
>>
>>
>>  After updating urllib3 library on my lab, commands like 'neutron net
>> list' began to throw warnings, like:
>>
>>> root@node-2:~# neutron net-list
>>> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
>>> InsecurePlatformWarning: A true SSLContext object is not available. This
>>> prevents urllib3 from configuring SSL appropriately and may cause certain
>>> SSL connections to fail. For more information, see
>>> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
>>> .
>>>   InsecurePlatformWarning
>>> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
>>> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
>>> for a `commonName` for now. This feature is being removed by major browsers
>>> and deprecated by RFC 2818. (See
>>> https://github.com/shazow/urllib3/issues/497 for details.)
>>>   SecurityWarning
>>>
>>> +--+---+---+
>>> | id   | name  | subnets
>>>   |
>>>
>>> +--+---+---+
>>> | 9e1c0866-51f0-4659-8d5c-1c5d0843dab4 | net04_ext |
>>> 29c952ec-2a13-46fc-a8a1-6e2468a92a95 172.18.171.0/24  |
>>> | d70b399b-668b-4861-b092-4876ec65df60 | net04 |
>>> b87fbfd1-0e52-4ab6-8987-286ef0912d1f 192.168.111.0/24 |
>>>
>>> +--+---+---+
>>>
>>
>> root@node-2:~#
>>
>>
>> Such urllib3 based warnings is only particular case. Warnings may appear
>> by another reason while call any Openstack utilities.
>>
>> Such warnings lead to broke work of puppet-neutron manifests:
>>
>>> 2015-10-20 16:42:11 +
>>> /Stage[main]/Main/Openstack::Network::Create_network[net04]/Neutron_network[net04]
>>> (info): Evaluated in 5.51 seconds
>>> 2015-10-20 16:42:11 + Puppet (debug): Prefetching neutron resources
>>> for neutron_subnet
>>> 2015-10-20 16:42:11 + Puppet (debug): Executing '/usr/bin/neutron
>>> subnet-list --format=csv --column=id --quote=none'
>>> 2015-10-20 16:42:13 + Puppet (debug): Executing '/usr/bin/neutron
>>> subnet-show --format=shell InsecurePlatformWarning'
>>> 2015-10-20 16:42:16 + Puppet::Type::Neutron_subnet::ProviderNeutron
>>> (notice): Unable to complete neutron request due to non-fatal error:
>>> "Execution of '/usr/bin/neutron subnet-show --format=shell
>>> InsecurePlatformWarning' returned 1:
>>> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
>>> InsecurePlatformWarning: A true SSLContext object is not available. This
>>> prevents urllib3 from configuring SSL appropriately and may cause certain
>>> SSL connections to fail. For more information, see
>>> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
>>> InsecurePlatformWarning
>>> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
>>> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
>>> for a `commonName` for now. This feature is being removed by major browsers
>>> and deprecated by RFC 2818. (See
>>> https://github.com/shazow/urllib3/issues/497 for details.)
>>>   SecurityWarningUnable to find subnet with name
>>> 'InsecurePlatformWarning'
>>> ". Retrying for 7 sec.
>>
>>  .
>>
>> Unable to find subnet with name 

Re: [openstack-dev] [all][heat] Which repo to use in docs -- git.openstack.org or github.com?

[Flavio Percoco]

On 20/10/15 18:34 +, Jeremy Stanley wrote:

On 2015-10-20 13:20:34 -0500 (-0500), Dolph Mathews wrote:
[...]

+1 I would never direct anyone new straight to git.openstack.org because it
makes a poor first impression relative to github.com. I assume that's the
reason why we keep github.com as a mirror at all (?).


Directing someone to a proprietary/non-open service seems like a far
worse impression to me.

We did look into a mechanism to auto-render README pages on the fly
in cgit, but any reasonably trivial implementation with its filter
mechanism made it hard to get to the non-rendered version of the
document. Ultimately we determined that putting work into making it
easier to render and publish documentation was a far better use of
our time than trying to turn a code browser into a documentation
viewer.

So if the question is whether to point people at git.openstack.org
or github.com as a homepage for a project, my recommendation is:
neither. Link them to your published documentation (and make sure it
includes information on where to browse and clone your source
code!).


Just want to say that I fully agree with the above. Well said!

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

[Sebastian Kalinowski]

2015-10-21 8:11 GMT+02:00 Mike Scherbakov :

>
> Simon is asking a valid request: if you add his folder in the file, he
> will be always added to the review request by script, once it's
> implemented. Only in the case when contribution is made to his particular
> area of responsibility.
>

Mike, when this sript will be implemented? It was promised long time ago
[1]. It is a important part of whole review process change and I doubt that
people would like to manually go
through MAINTAINERS with every review they post.

Also there was a request to add a job for validating MAINTAINERS file, how
is the progress with that?

[1] https://bugs.launchpad.net/fuel/+bug/1497655
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[Renat Akhmerov]

> On 20 Oct 2015, at 14:58, WANG, Ming Hao (Tony T) 
>  wrote:
> 
> Another question is:
> If I use custom action to run Ansible, the Ansible playbook should be stored 
> on the same server of Mistral. Is it right?

Depends on how this action is implemented (it can, for example, do ssh to other 
servers) but the simplest implementation would be with playbooks on the same 
server, yes.

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

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[Renat Akhmerov]

> On 19 Oct 2015, at 13:18, WANG, Ming Hao (Tony T) 
>  wrote:
> 
> I like your 
> option2(https://blueprints.launchpad.net/mistral/+spec/action-providers 
> ). J
> Any schedule for this? Looks like it isn’t started yet.

No particular plans yet. It’s been around for several months by now. It could 
be included in Mitaka as long as our resources allows to do that.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] core team nomination

[Qiming Teng]

+1 to both.

Qiming

On Tue, Oct 20, 2015 at 04:38:12PM +0300, Sergey Kraynev wrote:
> I'd like to propose new candidates for heat core-team:
> Rabi Mishra
> Peter Razumovsky
> 
> According statistic both candidate made a big effort in Heat as
> reviewers and as contributors [1][2].
> They were involved in Heat community work  during last several releases and
> showed good understanding of Heat code.
> I think, that they are ready to became core-reviewers.
> 
> Heat-cores, please vote with +/- 1.
> 
> [1] http://stackalytics.com/report/contribution/heat-group/180
> [2] http://stackalytics.com/?module=heat-group=person-day
> -- 
> Regards,
> Sergey.
> 
> __
> OpenStack Development Mailing 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] Custom Nova scheduler based on CPU queue length

[Clint Byrum]

Excerpts from Rahul Nair's message of 2015-10-20 18:53:09 -0700:
> ​Hi All,
> 
> I am fairly new to the OpenStack community and is trying to create a custom
> scheduler for Nova. A scheduler based on CPU queue length. Kindly apologize
> if there are any inaccuracies in my statements.
> 
> As I understand a weigher for the filter scheduler that weighs filtered
> host machines based on the host weight option, 'cpu.percent' can be
> configured to prioritize the hosts based on CPU percentage, but there are
> only limited options when it comes to filtering of machines in the first
> place, that too using the CPU queue length.
> 
> Also, I understand that IBM has its platform resource scheduler that can be
> used to build custom plugins to get user defined metrics, is there a
> similar way in pure Openstack which can be used to get the CPU queue length.
> 
> As of now, I am thinking of writing a custom script to be kept in all
> compute nodes to retrieve the CPU queue length and send it to the Nova
> controller, is this the way to go, or is there a defined approach that I
> can follow to implement a scheduler that uses CPU queue length to filter
> physical machines.
> 
> Any pointers on this would be really helpful.

Rahul, I'm realy curious about what it is you're trying to accomplish
here.

The CPU queue length is an extremely volatile statistic. Is this maybe
for a single-purpose cloud where you do have some idea what might be
running?

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

[openstack-dev] openstack-barbican-authenticate-keystone-barbican-command

[OpenStack Mailing List Archive]

Link: https://openstack.nimeyo.com/62868/?show=62868#q62868
From: marif82 

Hi Asha,

I am also getting the same error when I am executing the curl command to create secret. 

bash-4.2$ curl -X POST -H 'content-type:application/json' -H 'X-Project-Id:12345' -d '{"payload": "my-secret-here","payloadcontenttype": "text/plain"}' http://localhost:9311/v1/secrets
Authentication requiredbash-4.2$

Can you please help me how you have solved this problem. I am using the safenet HSM for MKEK and HMAC and it generated successfully on HSM partition.

Please help me to resolve this issue.

Thanks & Regards,
Arif



__
OpenStack Development Mailing 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] HenryG addition to the Neutron Drivers team

[Anna Kamyshnikova]

Congratulations Henry!

On Wed, Oct 21, 2015 at 8:49 AM, Kevin Benton  wrote:

> Excellent addition! Remember everyone, if the feature you want doesn't
> make it into Neutron, it's now Henry's fault. :)
>
> On Tue, Oct 20, 2015 at 8:14 PM, Armando M.  wrote:
>
>> Hi folks,
>>
>> Henry has been instrumental in many areas of the projects and his crazy
>> working hours makes even Kevin and I bow in awe.
>>
>> Jokes aside, I would like to announce HenryG as a new member of the
>> Neutron Drivers team.
>>
>> Having a propension to attendance, and desire to review of RFEs puts you
>> on the right foot to join the group, whose members are rotated regularly so
>> that everyone is given the opportunity to grow, and no-one burns out.
>>
>> The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
>> attend.
>>
>> Please, join me in welcome Henry to the team.
>>
>> Cheers,
>> Armando
>>
>> [1]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>>
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Regards,
Ann Kamyshnikova
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] [Fuel][Plugins] Plugin deployment questions

[Dmitriy Shulyak]

Hi,

Can we ignore the problem above and remove this limitation? Or should
> we improve it somehow so it would work for one nodes, and will be
> ignored for others?
>
I think that this validation needs to be accomplished in a different way,
we don't need 1 controller for the sake of 1 controller,
1 controller is a dependency of compute/cinder/other roles. So from my pov
there is atleast 2 options:

1. Use tasks dependencies, and prevent deployment in case if some tasks
relies on controller.
But the implementation might be complicated

2. Insert required metadata into roles that relies on another roles, for
compute it will be something like:
   compute:
 requires: controller > 1
We actually have DSL for declaring such things, we just need to specify
this requirements from other side.

But in 2nd case we will still need to use tricks, like one provided by
Matt, for certain plugins. So maybe we should spend time and do 1st.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

[Igor Kalnitsky]

Hi Dmitry,

> Insert required metadata into roles that relies on another roles, for
> compute it will be something like:
>
> compute:
> requires: controller > 1

Yeah, that's actually what I was thinking about when I wrote:

> Or should we improve it somehow so it would work for one nodes,
> and will be ignored for others?

So I'm +1 for extending our meta information with such dependencies.

Sincerely,
Igor

On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak  wrote:
> Hi,
>
>> Can we ignore the problem above and remove this limitation? Or should
>> we improve it somehow so it would work for one nodes, and will be
>> ignored for others?
>
> I think that this validation needs to be accomplished in a different way, we
> don't need 1 controller for the sake of 1 controller,
> 1 controller is a dependency of compute/cinder/other roles. So from my pov
> there is atleast 2 options:
>
> 1. Use tasks dependencies, and prevent deployment in case if some tasks
> relies on controller.
> But the implementation might be complicated
>
> 2. Insert required metadata into roles that relies on another roles, for
> compute it will be something like:
>compute:
>  requires: controller > 1
> We actually have DSL for declaring such things, we just need to specify this
> requirements from other side.
>
> But in 2nd case we will still need to use tricks, like one provided by Matt,
> for certain plugins. So maybe we should spend time and do 1st.
>
> __
> OpenStack Development Mailing 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] [ANNOUNCE] [HA] [Pacemaker] new, maintained openstack-resource-agents repository

[Adam Spiers]

[cross-posting to openstack-dev and pacemaker user lists; please
consider trimming the recipients list if your reply is not relevant to
both communities]

Hi all,

Back in June I proposed moving the well-used but no longer maintained
https://github.com/madkiss/openstack-resource-agents/ repository to
Stackforge:

  http://lists.openstack.org/pipermail/openstack-dev/2015-June/067763.html
  https://github.com/madkiss/openstack-resource-agents/issues/22

The responses I got were more or less unanimously in favour, so I'm
simultaneously pleased and slightly embarrassed to announce that 4
months later, I've finally followed up on my proposal:

  https://launchpad.net/openstack-resource-agents
  https://git.openstack.org/cgit/openstack/openstack-resource-agents/
  
https://review.openstack.org/#/admin/projects/openstack/openstack-resource-agents
  
https://review.openstack.org/#/q/status:open+project:openstack/openstack-resource-agents,n,z

Since June, Stackforge has been retired, so as you can see above, this
repository lives under the 'openstack' namespace.

I volunteered to be a maintainer and there were no objections.  I sent
out an initial call for co-maintainers but noone expressed an interest
which is probably fine because the workload is likely to be quite
light.  However if you'd like to be involved please drop me a line.

I've also taken care of outstanding pull requests and bug reports
against the old repository, and providing a redirect from the old
repository's README to the new one.

Still TODO: adding this repository to the Big Tent.  I've had some
discussions with the openstack-infra team about that, since there is
not currently a suitable project team to create it under.  We might
create a new project team called "OpenStack Pacemaker" or similar, and
place it under that.  ("OpenStack HA" would be far too broad to be
able to find a single PTL.)  However there is no rush for this, and it
has been suggested that it would not be a bad thing to wait for the
"new" project to stabilise and prove its longevity before making it
official.

Cheers,
Adam

P.S. I'll be in Tokyo if anyone wants to meet there and discuss
further.

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

Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11

[Daniel P. Berrange]

On Tue, Oct 13, 2015 at 05:08:29PM -0700, Zaro wrote:
> Hello All,
> 
> The openstack-infra team would like to upgrade from our Gerrit 2.8 to
> Gerrit 2.11.  We are proposing to do the upgrade shortly after the
> Mitaka summit.  The main motivation behind the upgrade is to allow us
> to take advantage of some of the new REST api, ssh commands, and
> stream events features.  Also we wanted to stay closer to upstream so
> it will be easier to pick up more recent features and fixes.

Looking at the release notes I see my most wanted new feature, keyword
tagging of changes, is available

[quote]
Hashtags.

Hashtags can be added to changes. The hashtags are stored in git notes and
are indexed in the secondary index.

This feature requires the notedb to be enabled.
[/quote]

It is listed as an experimental feature, but I'd really love to see this
enabled if at all practical.

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

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