Re: [openstack-dev] [networking-ovn] Re: [ovs-dev] Issue when using ovn with Openstack

[Chen Li]

Just Tested with another multi-node setup with older code (code download in
last week), and everything works.

Here are the last changes for workable ovs/neutron/networking-ovn:

ovs:

commit 3041e1fc963886c3e19f1b848df20c6f9d96b289
Author: William Tu 
Date:   Fri Jul 1 09:45:52 2016 -0700

system-traffic: Remove datapath specific tests and macro.

We generally try to keep the testsuite independent of the underlying
datapath. This patch removes the datapath-specific tests and macros.

Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/141642065
Signed-off-by: William Tu 
Signed-off-by: Joe Stringer 


neutron:

commit 2f29a5db3ca0a5a26571be07109bf49e57c0fc2d
Merge: 86c02d8 09a6a46
Author: Jenkins 
Date:   Thu Jul 14 23:24:58 2016 +

Merge "Pecan: Implement pagination"


networking-ovn:

commit 12919d0d48c63d252be4a42f3f20a2176b53f7d9
Merge: 381b57f 28b2c55
Author: Jenkins 
Date:   Thu Jul 14 23:36:10 2016 +

Merge "Grenade plugin for testing OVN migration from ML2/OVS"


On Wed, Jul 20, 2016 at 1:17 PM, Chen Li  wrote:

> Thanks for adding the openstack-dev.
>
> Yes, I'm running with devstack, and using the master branch of everything.
> I just updated every thing several hours ago to make sure this is not an
> issue already been fixed.
>
> The last change in neutron:
>
> commit 122a971656671f92927d44ddd3725cca74b4e0bb
> Merge: 827bb07 01a6c9c
> Author: Jenkins 
> Date:   Tue Jul 19 17:14:33 2016 +
>
> Merge "Generalize agent extension mechanism"
>
> The last change in networking-ovn:
>
> commit a8abf7517f86df6e0ff532cd49550b4dc3c0a9ed
> Author: Ryan Moats 
> Date:   Fri Jul 15 11:32:33 2016 -0500
>
> [doc] Prettify logical flow examples
>
> Rather than showing database objects, use the output of ovn-sbctl
> lflow-list, because it is prettier.
>
> Change-Id: I243b7316731c6c723bf6e64c9326800272643578
>
>
>
> I do not know where to find : neutron.ini and networking-ovn.ini, are you
> mean neutron.conf & networking-ovn.conf ? Could you point to me where I can
> find them ?
> I did no change to these configuration files after stack.sh finished.
>
> On Wed, Jul 20, 2016 at 12:42 PM, Ryan Moats  wrote:
>
>> "dev"  wrote on 07/19/2016 10:44:27 PM:
>>
>> > From: Chen Li 
>> > To: d...@openvswitch.org
>> > Date: 07/19/2016 10:44 PM
>> > Subject: [ovs-dev] Issue when using ovn with Openstack
>> > Sent by: "dev" 
>> >
>> > Hi list,
>> >
>> > I have an all-in-one devstack environment with ovn enabled.
>> > I create a neutron network.
>> > Create a port A from the network with secgroup A
>> > Create a vm from the network with secgroup B.
>> > Secgroup B has both ICMP  and tcp 22 enabled.
>> >
>> > Then I try to ping the VM from the dhcp namespace, since the Secgroup B
>> has
>> > enabled ICMP,  I suppose this should work. But, unfortunately,  this do
>> not
>> > work. And,  the ssh failed too.
>> >
>> > Anyone can help me to solve this issue ?
>> >
>> > I did some basic checks and looks like flows are missing in table 52.
>> >
>> > Here are flows in table 52:
>> >
>> > sudo ovs-ofctl dump-flows br-int |grep table=52
>> >
>> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
>> > idle_age=7766,
>> priority=65535,icmp6,metadata=0x4,icmp_type=135,icmp_code=0
>> > actions=resubmit(,53)
>> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
>> > idle_age=7766,
>> priority=65535,icmp6,metadata=0x4,icmp_type=136,icmp_code=0
>> > actions=resubmit(,53)
>> >  cookie=0x0, duration=7766.195s, table=52, n_packets=4, n_bytes=1474,
>> > idle_age=7744, priority=2002,udp,reg15=0x2,metadata=0x4,nw_src=
>> > 192.168.0.0/24,tp_src=67,tp_dst=68
>> > actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>> >  cookie=0x0, duration=7557.209s, table=52, n_packets=2, n_bytes=759,
>> > idle_age=7548, priority=2002,udp,reg15=0x3,metadata=0x4,nw_src=
>> > 192.168.0.0/24,tp_src=67,tp_dst=68
>> > actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
>> > idle_age=7766, priority=2001,ipv6,reg15=0x2,metadata=0x4 actions=drop
>> >  cookie=0x0, duration=7766.195s, table=52, n_packets=2, n_bytes=676,
>> > idle_age=7548, priority=2001,ip,reg15=0x2,metadata=0x4 actions=drop
>> >  cookie=0x0, duration=7557.209s, table=52, n_packets=0, n_bytes=0,
>> > idle_age=7557, priority=2001,ipv6,reg15=0x3,metadata=0x4 actions=drop
>> >  cookie=0x0, duration=7557.209s, table=52, n_packets=3979,
>> n_bytes=389774,
>> > idle_age=413, priority=2001,ip,reg15=0x3,metadata=0x4 actions=drop
>> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
>> > idle_age=7766, priority=1,ipv6,metadata=0x4
>> > 

Re: [openstack-dev] [networking-ovn] Re: [ovs-dev] Issue when using ovn with Openstack

[Chen Li]

Thanks for adding the openstack-dev.

Yes, I'm running with devstack, and using the master branch of everything.
I just updated every thing several hours ago to make sure this is not an
issue already been fixed.

The last change in neutron:

commit 122a971656671f92927d44ddd3725cca74b4e0bb
Merge: 827bb07 01a6c9c
Author: Jenkins 
Date:   Tue Jul 19 17:14:33 2016 +

Merge "Generalize agent extension mechanism"

The last change in networking-ovn:

commit a8abf7517f86df6e0ff532cd49550b4dc3c0a9ed
Author: Ryan Moats 
Date:   Fri Jul 15 11:32:33 2016 -0500

[doc] Prettify logical flow examples

Rather than showing database objects, use the output of ovn-sbctl
lflow-list, because it is prettier.

Change-Id: I243b7316731c6c723bf6e64c9326800272643578



I do not know where to find : neutron.ini and networking-ovn.ini, are you
mean neutron.conf & networking-ovn.conf ? Could you point to me where I can
find them ?
I did no change to these configuration files after stack.sh finished.

On Wed, Jul 20, 2016 at 12:42 PM, Ryan Moats  wrote:

> "dev"  wrote on 07/19/2016 10:44:27 PM:
>
> > From: Chen Li 
> > To: d...@openvswitch.org
> > Date: 07/19/2016 10:44 PM
> > Subject: [ovs-dev] Issue when using ovn with Openstack
> > Sent by: "dev" 
> >
> > Hi list,
> >
> > I have an all-in-one devstack environment with ovn enabled.
> > I create a neutron network.
> > Create a port A from the network with secgroup A
> > Create a vm from the network with secgroup B.
> > Secgroup B has both ICMP  and tcp 22 enabled.
> >
> > Then I try to ping the VM from the dhcp namespace, since the Secgroup B
> has
> > enabled ICMP,  I suppose this should work. But, unfortunately,  this do
> not
> > work. And,  the ssh failed too.
> >
> > Anyone can help me to solve this issue ?
> >
> > I did some basic checks and looks like flows are missing in table 52.
> >
> > Here are flows in table 52:
> >
> > sudo ovs-ofctl dump-flows br-int |grep table=52
> >
> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> > idle_age=7766,
> priority=65535,icmp6,metadata=0x4,icmp_type=135,icmp_code=0
> > actions=resubmit(,53)
> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> > idle_age=7766,
> priority=65535,icmp6,metadata=0x4,icmp_type=136,icmp_code=0
> > actions=resubmit(,53)
> >  cookie=0x0, duration=7766.195s, table=52, n_packets=4, n_bytes=1474,
> > idle_age=7744, priority=2002,udp,reg15=0x2,metadata=0x4,nw_src=
> > 192.168.0.0/24,tp_src=67,tp_dst=68
> > actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
> >  cookie=0x0, duration=7557.209s, table=52, n_packets=2, n_bytes=759,
> > idle_age=7548, priority=2002,udp,reg15=0x3,metadata=0x4,nw_src=
> > 192.168.0.0/24,tp_src=67,tp_dst=68
> > actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> > idle_age=7766, priority=2001,ipv6,reg15=0x2,metadata=0x4 actions=drop
> >  cookie=0x0, duration=7766.195s, table=52, n_packets=2, n_bytes=676,
> > idle_age=7548, priority=2001,ip,reg15=0x2,metadata=0x4 actions=drop
> >  cookie=0x0, duration=7557.209s, table=52, n_packets=0, n_bytes=0,
> > idle_age=7557, priority=2001,ipv6,reg15=0x3,metadata=0x4 actions=drop
> >  cookie=0x0, duration=7557.209s, table=52, n_packets=3979,
> n_bytes=389774,
> > idle_age=413, priority=2001,ip,reg15=0x3,metadata=0x4 actions=drop
> >  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> > idle_age=7766, priority=1,ipv6,metadata=0x4
> > actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
> >  cookie=0x0, duration=7766.195s, table=52, n_packets=8, n_bytes=2733,
> > idle_age=7548, priority=1,ip,metadata=0x4
> > actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
> >  cookie=0x0, duration=7926.354s, table=52, n_packets=0, n_bytes=0,
> > idle_age=7926, priority=0,metadata=0x1 actions=resubmit(,53)
> >  cookie=0x0, duration=7790.771s, table=52, n_packets=129, n_bytes=5418,
> > idle_age=408, priority=0,metadata=0x4 actions=resubmit(,53)
> >
> > Here are steps how I find flows are missing in table52:
> >
> > ovs-dpctl show
> >
> > port 0: ovs-system (internal)
> > port 1: br-int (internal)
> > port 2: tap446ef382-f0 (internal)
> > port 3: tapc7c9f581-2d (internal)  => the dhcp port for the testing
> > network
> > port 4: o-hm0 (internal)=> the port create from the
> > testing network with security group A
> > port 5: tap275a5a25-79   => the port for the vm in the
> > testing network with security group B
> >
> >
> > sudo ip netns exec qdhcp-e8586b01-6441-4c3d-a90d-91bb0a54ec80 arp -n
> >
> > Address  HWtype  HWaddress   Flags Mask
> > Iface
> > 192.168.0.6  ether   fa:16:3e:40:85:41   C
> > tapc7c9f581-2d
> > 192.168.0.12 ether   fa:16:3e:5c:fe:86   C
> > tapc7c9f581-2d
> >
> >
> > 

[openstack-dev] [networking-ovn] Re: [ovs-dev] Issue when using ovn with Openstack

[Ryan Moats]

"dev"  wrote on 07/19/2016 10:44:27 PM:

> From: Chen Li 
> To: d...@openvswitch.org
> Date: 07/19/2016 10:44 PM
> Subject: [ovs-dev] Issue when using ovn with Openstack
> Sent by: "dev" 

>
> Hi list,
>
> I have an all-in-one devstack environment with ovn enabled.
> I create a neutron network.
> Create a port A from the network with secgroup A
> Create a vm from the network with secgroup B.
> Secgroup B has both ICMP  and tcp 22 enabled.
>
> Then I try to ping the VM from the dhcp namespace, since the Secgroup B
has
> enabled ICMP,  I suppose this should work. But, unfortunately,  this do
not
> work. And,  the ssh failed too.
>
> Anyone can help me to solve this issue ?
>
> I did some basic checks and looks like flows are missing in table 52.
>
> Here are flows in table 52:
>
> sudo ovs-ofctl dump-flows br-int |grep table=52
>
>  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> idle_age=7766,
priority=65535,icmp6,metadata=0x4,icmp_type=135,icmp_code=0
> actions=resubmit(,53)
>  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> idle_age=7766,
priority=65535,icmp6,metadata=0x4,icmp_type=136,icmp_code=0
> actions=resubmit(,53)
>  cookie=0x0, duration=7766.195s, table=52, n_packets=4, n_bytes=1474,
> idle_age=7744, priority=2002,udp,reg15=0x2,metadata=0x4,nw_src=
> 192.168.0.0/24,tp_src=67,tp_dst=68
> actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>  cookie=0x0, duration=7557.209s, table=52, n_packets=2, n_bytes=759,
> idle_age=7548, priority=2002,udp,reg15=0x3,metadata=0x4,nw_src=
> 192.168.0.0/24,tp_src=67,tp_dst=68
> actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> idle_age=7766, priority=2001,ipv6,reg15=0x2,metadata=0x4 actions=drop
>  cookie=0x0, duration=7766.195s, table=52, n_packets=2, n_bytes=676,
> idle_age=7548, priority=2001,ip,reg15=0x2,metadata=0x4 actions=drop
>  cookie=0x0, duration=7557.209s, table=52, n_packets=0, n_bytes=0,
> idle_age=7557, priority=2001,ipv6,reg15=0x3,metadata=0x4 actions=drop
>  cookie=0x0, duration=7557.209s, table=52, n_packets=3979,
n_bytes=389774,
> idle_age=413, priority=2001,ip,reg15=0x3,metadata=0x4 actions=drop
>  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> idle_age=7766, priority=1,ipv6,metadata=0x4
> actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>  cookie=0x0, duration=7766.195s, table=52, n_packets=8, n_bytes=2733,
> idle_age=7548, priority=1,ip,metadata=0x4
> actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>  cookie=0x0, duration=7926.354s, table=52, n_packets=0, n_bytes=0,
> idle_age=7926, priority=0,metadata=0x1 actions=resubmit(,53)
>  cookie=0x0, duration=7790.771s, table=52, n_packets=129, n_bytes=5418,
> idle_age=408, priority=0,metadata=0x4 actions=resubmit(,53)
>
> Here are steps how I find flows are missing in table52:
>
> ovs-dpctl show
>
> port 0: ovs-system (internal)
> port 1: br-int (internal)
> port 2: tap446ef382-f0 (internal)
> port 3: tapc7c9f581-2d (internal)  => the dhcp port for the testing
> network
> port 4: o-hm0 (internal)=> the port create from the
> testing network with security group A
> port 5: tap275a5a25-79   => the port for the vm in the
> testing network with security group B
>
>
> sudo ip netns exec qdhcp-e8586b01-6441-4c3d-a90d-91bb0a54ec80 arp -n
>
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 192.168.0.6  ether   fa:16:3e:40:85:41   C
> tapc7c9f581-2d
> 192.168.0.12 ether   fa:16:3e:5c:fe:86   C
> tapc7c9f581-2d
>
>
> sudo ip netns exec qdhcp-e8586b01-6441-4c3d-a90d-91bb0a54ec80 ping
> 192.168.0.12  => This is the IP for the VM.
> PING 192.168.0.12 (192.168.0.12) 56(84) bytes of data.
>
>
> ovs-dpctl dump-flows
>
> recirc_id(0),in_port(3),eth(src=fa:16:3e:b6:f6:25,dst=fa:16:3e:
> 5c:fe:86),eth_type(0x0806),arp(sip=192.168.0.2,tip=192.168.0.
> 12,op=1/0xff,sha=fa:16:3e:b6:f6:25,tha=00:00:00:00:00:00),
> packets:0, bytes:0, used:never,
> actions:userspace(pid=4294958325,slow_path(action))
> recirc_id(0),in_port(3),eth(src=00:00:00:00:00:00/01:00:00:00:00:
> 00,dst=fa:16:3e:5c:fe:86),eth_type(0x0800),ipv4(src=
> 192.168.0.0/255.255.255.0,proto=1,frag=no), packets:14, bytes:1372,
> used:0.974s, actions:drop
>
>
> sudo ovs-appctl ofproto/trace
> "recirc_id(0),in_port(3),eth(src=00:00:00:00:00:00/01:00:00:00:00:
> 00,dst=fa:16:3e:5c:fe:86),eth_type(0x0800),ipv4(src=
> 192.168.0.0/255.255.255.0,proto=1,frag=no)"
> => This produce a long output, and here are the end of the output:
>
> OpenFlow actions=resubmit(,52)
>
> Resubmitted flow: unchanged
>
> Resubmitted regs: reg0=0x1 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0
> reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0
> reg13=0x0 reg14=0x1 reg15=0x3
>
> Resubmitted  odp: drop
>
> Resubmitted megaflow:
>

[openstack-dev] 答复: [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

[hu . zhijiang]

OK, we got a consensus.

I will add Wei as core committor soon.


B.R.,
Zhijiang




发件人: LuYao00184532/user/zte_ltd
收件人: HuZhiJiang180967/user/zte_ltd@ZTE_LTD, 
抄送:   openstack-dev@lists.openstack.org, huzhiji...@gmail.com, 
zhou...@zte.com.cn, sun.jin...@zte.com.cn, kong.w...@zte.com.cn, 
janonymous.codevult...@gmail.com, WuWei10166727/user/zte_ltd@ZTE_LTD
日期:   2016-07-19 11:59
主题:   答复: [daisycloud-core] Nnominate Wei Kong as core for 
daisycloud-core project


+1





发件人: 胡智江180967/user/zte_ltd
收件人: openstack-dev@lists.openstack.org, huzhiji...@gmail.com, 
lu.yao...@zte.com.cn, zhou...@zte.com.cn, sun.jin...@zte.com.cn, 
kong.w...@zte.com.cn, janonymous.codevult...@gmail.com, 
WuWei10166727/user/zte_ltd@ZTE_LTD, HuZhiJiang180967/user/zte_ltd@ZTE_LTD, 

日期:   2016/07/19 10:21
主题:   [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core 
project


Hi Team,

I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the 
daisycloud-core core team. He has good experience on openstack
development, previously he lead another team finished a BP of a 
cinder driver and his current commitment is on testing, ci for 
daisycloud-core. Until recently, He built flake8 test and deal most 
of the problems in the code, and he is working on build tempest for 
us now.



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing 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] [tricircle]agenda of weekly meeting Jul.20

[joehuang]

Hi, team,


IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every 
Wednesday starting from UTC 13:00.



The agenda of this weekly meeting is:

# microversion support

# Tricircle API feature paity planning:

  *   
https://docs.google.com/spreadsheets/d/1yXdxGtQq_6YJUtJtjmPICyhq4SbP8E6uWyzn0zev8bI/edit#gid=308439069

# todo list review https://etherpad.openstack.org/p/TricircleToDo (API feature 
parity was just added, and microversion support's priority is prompted)


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

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

Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type

[Qiming Teng]

On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:
> Hello!
> 
> Today it was announced that Glare is ready for public review
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html So
> we are ready to start working on integration Heat with Glare and
> implementing a POC. After discussions with Glare team we see two design
> options:
> 
> 1) Create one artifact type that will contain template, nested templates
> and environments.
> Pros: It is easy to maintain integrity. Since artifact is immutable, we can
> guarantee the consistency and prevent from accidentally removing of
> dependent environment.
> Cons: If we need to add new environments to use them with template, we need
> to create new artifact.
> 
> 2) Create 2 artifact types: environment and template.
> Pros: It is easy to add new environments. You just need to create new
> dependency from template artifact to environment one.
> Cons: Some environment can be (mistakenly) removed, and template that have
> dependencies on it will be in inconsistent state.

Option 2 looks more flexible to me. I'm not sure we are encouraging
users to introduce or rely on a hard dependency from a template to an
environment file. With that, it is still good to know whether glare
supports the concept of 'reference' where a referenced artifact cannot
be deleted.

 - Qiming
 
> So we want to hear your opinions and suggestions on the matter. Thanks in
> advance!
> 
> Best regards,
> Oleksii Chuprykov


__
OpenStack Development Mailing List (not for 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] What is Magnum's behaviour wrt Images in Glance and which ones are downloaded to COE ?

[taget]

On 2016年07月20日 00:35, Waines, Greg wrote:


Does MAGNUM automatically download all Glance Images of a particular 
Container Format to the COE ?



No, Magnum will not do this.
Only  the swarm docker image is download by Magnum.


In the above setup, which Glance Image does the ‘docker image’ 
“cirros” correspond to ?



None of from glance image.

You launched the swarm docker container with image 'cirros', the image 
of 'cirros' was downloaded by docker daemon which is from OFFICIAL image 
hub from https://hub.docker.com/


--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.

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

Re: [openstack-dev] [devstack] How to enable SSL in devStack?

[Wenzhi Yu (yuywz)]

Thanks for your reply, Andrey. I tried set USE_SSL=True but still got the same 
error:

2016-07-20 01:29:21.446 | Discovering versions from the identity service failed 
when creating the password plugin. Attempting to determine version from URL.
2016-07-20 01:29:21.446 | Could not determine a suitable URL for the plugin.

Please see the detailed log here: http://paste.openstack.org/show/538761/
Here is my local.conf: http://paste.openstack.org/show/538762/

2016-07-20



Best Regards,
Wenzhi Yu (yuywz)



发件人：Andrey Pavlov 
发送时间：2016-07-19 16:46
主题：Re: [openstack-dev] [devstack] How to enable SSL in devStack?
收件人："OpenStack Development Mailing List (not for usage 
questions)"
抄送：

just add 

USE_SSL=True 

to your localrc before run stack.sh 

Regards, 
Andrey. 

On Tue, Jul 19, 2016 at 10:17 AM, Wenzhi Yu (yuywz)  wrote: 
> Hi folks, 
> 
> I want to configure the openstack endpoints to use SSL in devStack. 
> 
> I searched on internet and found some posts like [1] and tried the 
> configuration in the post, but devStack script failed with error messages 
> like: 
> "Discovering versions from the identity service failed when creating the 
> password plugin. Attempting to determine version from URL. Could not 
> determine a suitable URL for the plugin." 
> [1]https://ask.openstack.org/en/question/45348/devstack-with-ssl/ 
> 
> So how to enable SSL in devStack? Can anyone please give me some guidance? 
> Thanks! 
> 
> 2016-07-19 
>  
> Best Regards, 
> Wenzhi Yu (yuywz) 
> 
> __ 
> OpenStack Development Mailing List (not for usage questions) 
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 



--  
Kind regards, 
Andrey Pavlov. 

__ 
OpenStack Development Mailing 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] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

[Jamie Lennox]

On 20 July 2016 at 00:06, Joshua Harlow  wrote:

> Hayes, Graham wrote:
>
>> On 18/07/16 22:27, Ronald Bradford wrote:
>>
>>> Hi All,
>>>
>>> For Oslo libraries we ensure that API's are backward compatible for 1+
>>> releases.
>>> When an Oslo API adds a new class attribute (as in this example of
>>> is_admin_project and 4 other attributes) added to Oslo Context in
>>> 2.6.0,  these are added to ensure this API is also forward compatible
>>> with existing project code for any contract with the base class
>>> instantiation or manipulation.
>>>
>>
>> Which projects is this run against?
>>
>> The issue seen is presently Nova specific (as other projects can
>>> utilize 2.6.0) and it is related to projects that sub-class
>>> oslo.context, and how unit tests are written for using class
>>> parameters.  Ideally, to implement using oslo.context correctly
>>> OpenStack projects should:
>>>
>>
>> Designate also had to make a quick change to support 2.6.0.
>>
>> We were lucky as it was noticed by the RDO builds, which had pulled in
>> 2.6.0 before the requirements update was proposed, so it did not break
>> our gate.
>>
>> I just did a quick search and there is a few projects that hardcoded
>> this, like we did.
>>
>
> Ya, that's bad, nothing in the docs of the to_dict API say what to even
> compare against (or the keys produced), so I'm pretty sure anyone doing
> this is setting themselves up for future failure and fragile software.
>

Can you post that list?


>
>
>> * Not perform direct dictionary to dictionary comparisons with the
>>> to_dict() method as this does not support when new attributes at
>>> added. Two patches (one to nova) address this in offending projects
>>> [5][6]
>>> * Unit tests should focus on attributes specific to the sub-classed
>>> signature, e.g. [7].  Oslo context provides an extensive set of unit
>>> tests for base class functionality. This is a wish list item for
>>> projects to implement.
>>>
>>> The to_dict() method exists as a convenience method only and is not an
>>> API contract. The resulting set of keys should be used accordingly.
>>> This is why there is no major release version.
>>>
>>
>> How are developers supposed to know that?
>>
>
> So we (in oslo) can (and ideally will) make this better but when the API
> doesn't itself tell you what keys are produced or what the values of those
> keys are then it should be pretty obvious to u (the library user) that u
> can not reliably do dictionary comparisons (because how do u know what to
> compare against when the docs don't state that?). I suppose people are
> 'reverse engineering the dict' by just looking at the code but that's also
> not so great...
>

I think the obvious and only thing you should expect from the to_dict
method is that it can be reversed by the from_dict method. Subclasses can
then make small modifications to those methods to add additional
information as appropriate. There is a bit of a problem in this with the
way subclasses are done that is fixed in [1] but it does not affect any
existing code.

We realize that the to_dict method is subclassed by a lot of services and
affects RPC and so contexts must be serializable between different versions
of the library so we will not modify existing to_dict values but as
mentioned writing your tests to assume this will never be added to sets us
up for these problems.

In this case oslo.context was largely extracted from nova and so the
fragile tests make sense and should therefore be fixed - but the oslo
change does not constitute a breaking API change.


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


>
>
>> This kind of feels like semantics. This was an external API that changed
>> and as a result should have been a major version.
>>
>
> I think this is where it gets a little bit into as u said, semantics, but
> the semantics IMHO are important here because it affects the ability of
> oslo.context to move forward & change.
>
> I suppose we should/could just put a warning on this method like I did in
> taskflow (for something similar) @
> https://github.com/openstack/taskflow/blob/master/taskflow/engines/base.py#L71
> to denote that nothing in the dict that is returned can be guaranteed to
> always be the same.
>
>
>
>> There is a note from our discussion in Oslo to improve our
>>> documentation to describe the API use of to_dict() better and state we
>>> will not remove to_dict() keys within a release, but that may happen
>>> between releases.
>>>
>>> There is a subsequent problem with how Nova performs a warning test
>>> [8]. Additional reviews are looking at addressing this sub-class usage
>>> of from_dict() and to_dict().
>>>
>>> Regards
>>>
>>> Ronald
>>>
>>>
>>> [5] https://review.openstack.org/#/c/343694/,
>>> [6] https://review.openstack.org/#/c/342367/
>>> [7] https://review.openstack.org/#/c/342869/
>>> [8]
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144
>>>
>>> On Mon, Jul 18, 2016 at 10:50 AM, 

Re: [openstack-dev] [Glance][Heat][Murano][App-Catalog][Tacker] Glare is ready for wider review

[Sridhar Ramaswamy]

This is great! This is something we have penciled in to take up for Tacker.

We would love to start collaborating with your team to explore ways to
store various Tacker  (TOSCA) templates like VNFD, FFGD, NSD, etc in
Glare instead of in Tacker db tables. We have an agenda item on this
in our upcoming midcycle meetup [1]. It will be great if you can join
that session to help us kick start this effort.

- Sridhar

[1] https://etherpad.openstack.org/p/tacker-newton-midcycle

On Tue, Jul 19, 2016 at 4:31 AM, Mikhail Fedosin  wrote:
> Hello! Today I'm happy to announce that Glare's code is done and the service
> is ready for review [1].
>
> Glare (from GLance Artifact REpository) is a new service in the Glance
> project that provides a secure and customizable unified binary repository
> for OpenStack [2].
>
> The idea behind Glare is to allow various OpenStack services to catalog
> different binary objects they use to operate. Images used by Nova to run the
> VMs are just the best known examples of such objects; other examples include
> Heat templates, Tacker blueprints, Murano packages, and so on. Obviously,
> this functionality is common for different kinds of objects, and is usually
> unrelated to the primary mission of respective projects using these objects.
> That's why we implemented a dedicated service that will take care of
> managing various data assets in OpenStack clouds.
>
> This service fills a vacant niche in OpenStack and is intended to become a
> unified catalog of structured meta-information, as well as related binary
> data (with these objects comprising the 'artifacts'). In general Glare
> provides next key functionality, it:
>   * stores the objects reliably;
>   * guarantees their immutability once they're stored;
>   * provides search capabilities to find objects in the catalog;
>   * controls access to the objects by enforcing usage and modification
> policies, sharing and publication scenarios and so on;
>   * returns the detailed info about the requested objects;
>   * enables fetching of objects and manages their lifecycle;
>   * supports import/export the objects between clouds.
>
> Our next steps are related to help integrate various projects with Glare and
> implement artifact types for them [3]. Currently we are working with Heat,
> Murano and App-Catalog teams, but if you have any binary assets you want to
> catalog reliably - feel free to contact me and we will help your project to
> get the same functionality like Nova gets from Glance.
>
> Links:
> [1] Glare's code top commit: https://review.openstack.org/#/c/330459/5
> [2] Merged Glare API spec: https://review.openstack.org/#/c/283136/
> [3] Prototype of Heat artifact type:
> https://review.openstack.org/#/c/292327/46/glance/objects/heat-templates.py
>
> Best regards.
> Mikhail Fedosin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Magnum] Does Docker-Swarm not support inter-node/vm inter-container networking ?

[Ton Ngo]

Hi Greg,
 This is a capability that we are working on at this time:  enabling
Docker libnetwork using the Kuryr driver.
This will let you set up networks where the containers are connected to and
they will be allocated unique routable IP.
In the current default networking mode, you can still let container
provides service to each other through Docker
port mapping.  The end point for the container service would be the IP
address of the VM where the container is hosted
together with the port mapped.   You just cannot ping from one container to
another across VM's in this mode.
Ton Ngo,




From:   "Waines, Greg" 
To: "openstack-dev@lists.openstack.org"

Date:   07/19/2016 11:12 AM
Subject:[openstack-dev] [Magnum] Does Docker-Swarm not support
inter-node/vm inter-container networking ?



I have successfully setup devstack with Magnum,
following this link
https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst#building-and-using-a-swarm-bay

I created a Docker-Swarm bay and successfully launched some simple
containers.

I noticed that Docker-Swarm’s Container Networking Solution seems to simply
be an SNAT on its swarm-node VM.
And noticed that Docker-Swarm assigns the same Container subnet to each
swarm-node VM … and re-uses Container IP Addresses from this subnet across
swarm-node VMs.

Given this … it does not appear that Docker-Swarm can support networking
between two containers on different swarm-node VMs.
Is this True ?
OR
Is there a configuration option, thru Magnum or Docker-Swarm to enable this
inter-node inter-container Networking ?

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


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

Re: [openstack-dev] FPGA as a dynamic nested resources

[Ed Leafe]

On Jul 19, 2016, at 2:58 PM, Chris Friesen  wrote:

>> Why would a VM program the slot? Wouldn’t it usually be at the host level?
> 
> Are there no cases where a VM might want to download a proprietary program 
> into an FPGA?

That doesn’t sound right to me, but maybe I’m just not that familiar with FPGA 
specifics. In general, VMs don’t control their hosts. It would also bring up 
some complications, such as what should happen when you delete that VM: does 
the FPGA have to be reset to its original state?

>> I’m still not seeing the need for nesting. If you have a single FPGA with 8 
>> slots, when you program the slots with accelerators, you now have 8 
>> consumable resources. The fact that they came from a particular FPGA unit 
>> doesn’t seem relevant from a scheduling perspective.
> 
> If you want to be able to provide an FPGA as either a whole un-programmed 
> FPGA or as pre-programmed resources, you'd presumably need to know which 
> whole FPGAs are available and which have been fractionally allocated, no?

An unprogrammed FPGA is a particular resource class. When you program it, you 
are removing one of that class and creating one or more of a new resource class 
(e.g., an encryption accelerator program). There isn’t a need to nest anything.

> I agree that if you are only going to have the host program the FPGA and then 
> make the resources available then the scheduler doesn't need to know about 
> whole FPGAs.

That was where we left the discussion in Austin, so that was my assumption.


-- Ed Leafe






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

Re: [openstack-dev] [glance][nova] Globally disabling hw_qemu_guest_agent support

[Daniel Russell]

Hi Daniel,

Fair enough.  I don't personally understand your stance against having a 
configuration option to specifically disable guest agent but imagine there 
would be advantages to having a more generic implementation that can handle 
more use-cases (any property instead of just a specific property).  I imagine 
there will need to be a nova scheduler component to it as well (Or we might 
schedule an instance on a hypervisor that is configured not to allow it).

Is there a blueprint or spec for this kind of thing yet?  I can help put one 
together if there is interest but the implementation is probably for more 
seasoned developers.

Regards,
Dan.

-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com] 
Sent: Tuesday, 19 July 2016 6:39 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [glance][nova] Globally disabling 
hw_qemu_guest_agent support

On Tue, Jul 19, 2016 at 12:51:07AM +, Daniel Russell wrote:
> Hi Erno,
> 
> For the size of team I am in I think it would work well but it feels 
> like I am putting the security of Nova in the hands of Glance.

Yep, from an architectural pov it is not very good. Particularly in a 
multi-hypervisor compute deployment you can have the situation where yoyu want 
to allow a property for one type of hypervisor but forbid it for another.

What we really need is the exact same image property security restrictions 
implemented by nova-compute, so we can setup compute nodes to blacklist certain 
properties.

> 
> What I was more after was a setting in Nova that says 'this hypervisor 
> does not allow guest sockets and will ignore any attempt to create 
> them', 'this hypervisor always creates guest sockets regardless of 
> your choice', 'this hypervisor will respect whatever you throw in 
> hw_qemu_guest_agent with a default of no', or 'this hypervisor will 
> respect whatever you throw in hw_qemu_guest_agent with a default of 
> yes'.  It feels like a more appropriate place to control and manage that kind 
> of configuration.

Nope, there's no such facility right now - glance property protection is the 
only real option. I'd be very much against adding a lockdown which was specific 
to the guest agent too - if we did anything it would be to have a generic 
property protection model in nova that mirrors what glance supports.

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

__
OpenStack Development Mailing List (not for 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][all] Big tent? (Related to Plugins for all)

[Clint Byrum]

Excerpts from Fox, Kevin M's message of 2016-07-19 21:59:29 +:
> Yeah. I'm not saying any project has done it out of malice. Everyone's just 
> doing whats best for their project. But it does not seem like there is an 
> overarching entity watching over the whole or (pushing, encouraging, 
> enticing, whatever words are appropriate here) projects to work on the 
> commons anymore. It use to be that incubating projects were pushed to help 
> the other projects integrate with them by the incubating project being 
> strongly encouraged to write the integrations themselves as part of the 
> incubation process. Now it seems like each project just spawns and then hopes 
> someone else will do the legwork. Using the carrot of incubation to further 
> the commons is not an ideal solution, but it was at least something.
> 
> Linux has an overarching entity, Linus for that task. He's there to make sure 
> that someone is really paying attention to integration of the whole thing 
> into a cohesive, usable whole. Sometimes he pushes back and makes sure 
> commons work happens as part of features getting in to ensure commons work 
> still gets done. I'm not advocating a benevolent dictator for OpenStack 
> though.
> 
> But what I thought what the TC's job was, was benevolent dictators, which 
> each subproject (or subsystem in linux terms) are required to give up final 
> say to, so that sometimes the projects have to sacrifice a bit so that the 
> whole can flourish and those benevolent dictators are elected for a time, by 
> the OpenStack community. (Actually, I think  that kind of makes it a 
> Democratic Republic... but I digress) Maybe I misunderstood what the TC's 
> about. But I think we still do need some folks elected by the community to be 
> involved in making sure OpenStack as a whole has a cohesive technical 
> architecture that actually addresses user problems and that have some power 
> to to stop the "this feature belongs in this project", "no, it belongs in 
> that project", "no, lets spawn 3 new projects to cover that case" kinds of 
> things, make the difficult decision, and ask a project to help the community 
> out by going along with "a solution" and we all can move on. Critical 
> features have been stuck 
>  in this space for years and OpenStacks competitors have had solutions for 
> years. 

You're right, this is the TC's job. However, the TC does it more by
exception, rather than by default. So while Linus and the subsystem
leaders in the kernel look after changes in general, the TC is there to
catch things that bubble out of the processes in place. So, I think the
TC needs contributors to bring _specific_ things that need to be handled,
and they will. They're just not going to be able to stand at the gate
and review every spec... this process only scales to the velocity and
breadth that OpenStack has if we get contributors involved.

__
OpenStack Development Mailing List (not for 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][all] Big tent? (Related to Plugins for all)

[Fox, Kevin M]

Yeah. I'm not saying any project has done it out of malice. Everyone's just 
doing whats best for their project. But it does not seem like there is an 
overarching entity watching over the whole or (pushing, encouraging, enticing, 
whatever words are appropriate here) projects to work on the commons anymore. 
It use to be that incubating projects were pushed to help the other projects 
integrate with them by the incubating project being strongly encouraged to 
write the integrations themselves as part of the incubation process. Now it 
seems like each project just spawns and then hopes someone else will do the 
legwork. Using the carrot of incubation to further the commons is not an ideal 
solution, but it was at least something.

Linux has an overarching entity, Linus for that task. He's there to make sure 
that someone is really paying attention to integration of the whole thing into 
a cohesive, usable whole. Sometimes he pushes back and makes sure commons work 
happens as part of features getting in to ensure commons work still gets done. 
I'm not advocating a benevolent dictator for OpenStack though.

But what I thought what the TC's job was, was benevolent dictators, which each 
subproject (or subsystem in linux terms) are required to give up final say to, 
so that sometimes the projects have to sacrifice a bit so that the whole can 
flourish and those benevolent dictators are elected for a time, by the 
OpenStack community. (Actually, I think  that kind of makes it a Democratic 
Republic... but I digress) Maybe I misunderstood what the TC's about. But I 
think we still do need some folks elected by the community to be involved in 
making sure OpenStack as a whole has a cohesive technical architecture that 
actually addresses user problems and that have some power to to stop the "this 
feature belongs in this project", "no, it belongs in that project", "no, lets 
spawn 3 new projects to cover that case" kinds of things, make the difficult 
decision, and ask a project to help the community out by going along with "a 
solution" and we all can move on. Critical features have been stuck in this 
 space for years and OpenStacks competitors have had solutions for years.

Interest in OpenStack as a whole has leveled off in about 2014, while interest 
in other clouds have continued to grow:
https://www.google.com/trends/explore#q=%2Fm%2F0cm87w_%2C%20%2Fm%2F05nrgx%2C%20%2Fm%2F04y7lrx=q=Etc%2FGMT%2B7

If the trend of OpenStack as a whole is not rising, we need to figure out why 
and get the whole moving again. I think thats mostly the projects keeping their 
heads down and working on what they work on, and not much focus on the commons, 
or helping OpenStack as a whole get better, other then what just happens as a 
side effect of each project gaining features.

We need to figure out how to fix this.

Thanks,
Kevin

From: Zane Bitter [zbit...@redhat.com]
Sent: Tuesday, July 19, 2016 1:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On 14/07/16 16:30, Fox, Kevin M wrote:
> I'm going to go ahead and ask the difficult question now as the answer is 
> relevant to the attached proposal...
>
> Should we reconsider whether the big tent is the right approach going forward?
>
> There have been some major downsides I think to the Big Tent approach, such 
> as:
>  * Projects not working together because of fear of adding extra dependencies 
> Ops don't already have
>  * Reimplementing features, badly, over and over again in different projects 
> instead of standardizing something.
>  * More projects being created due to politics and not technical reasons.
>  * Less cross project communication
>  * Greater Operator pain at trying to assemble a more loose confederation of 
> projects into something useful.
>  * General pushing off more and more work to Operators/Users to deal with.
>  * Worse User experience as cross project issues aren't being addressed.
>  * Previously incubated projects such as Nova, Swift, etc getting a 
> disproportionate say in things as they have a greater current user base, and 
> its increasingly hard now for new projects to gain any traction.
>  * Much less community pressure on projects to work together to elevate 
> everyone. Architectural decisions are now made at individual project level 
> with little done at the OpenStack level.
>  * etc...

The thing is, all of these problems pre-date the big tent. Arguably they
were even worse before because so many projects were not only not
blessed by the TC as hard dependencies, but officially weren't even part
of OpenStack. Say what you want about the big tent, but at least we
haven't been treated to another Zaqar graduation review farce.

I think your complaint here is that the big tent hasn't done enough to
solve these problems. That's a fair complaint.

I think what you're suggesting is missing is some sort of TC imprimatur
to say that 

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Fox, Kevin M]

Yeah. I'm not saying any project has done it out of malice. Everyone's just 
doing whats best for their project. But it does not seem like there is an 
overarching entity watching over the whole or (pushing, encouraging, enticing, 
whatever words are appropriate here) projects to work on the commons anymore. 
It use to be that incubating projects were pushed to help the other projects 
integrate with them by the incubating project being strongly encouraged to 
write the integrations themselves as part of the incubation process. Now it 
seems like each project just spawns and then hopes someone else will do the 
legwork. Using the carrot of incubation to further the commons is not an ideal 
solution, but it was at least something.

Linux has an overarching entity, Linus for that task. He's there to make sure 
that someone is really paying attention to integration of the whole thing into 
a cohesive, usable whole. Sometimes he pushes back and makes sure commons work 
happens as part of features getting in to ensure commons work still gets done. 
I'm not advocating a benevolent dictator for OpenStack though.

But what I thought what the TC's job was, was benevolent dictators, which each 
subproject (or subsystem in linux terms) are required to give up final say to, 
so that sometimes the projects have to sacrifice a bit so that the whole can 
flourish and those benevolent dictators are elected for a time, by the 
OpenStack community. (Actually, I think  that kind of makes it a Democratic 
Republic... but I digress) Maybe I misunderstood what the TC's about. But I 
think we still do need some folks elected by the community to be involved in 
making sure OpenStack as a whole has a cohesive technical architecture that 
actually addresses user problems and that have some power to to stop the "this 
feature belongs in this project", "no, it belongs in that project", "no, lets 
spawn 3 new projects to cover that case" kinds of things, make the difficult 
decision, and ask a project to help the community out by going along with "a 
solution" and we all can move on. Critical features have been stuck in this 
 space for years and OpenStacks competitors have had solutions for years. 

Interest in OpenStack as a whole has leveled off in about:


From: Zane Bitter [zbit...@redhat.com]
Sent: Tuesday, July 19, 2016 1:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On 14/07/16 16:30, Fox, Kevin M wrote:
> I'm going to go ahead and ask the difficult question now as the answer is 
> relevant to the attached proposal...
>
> Should we reconsider whether the big tent is the right approach going forward?
>
> There have been some major downsides I think to the Big Tent approach, such 
> as:
>  * Projects not working together because of fear of adding extra dependencies 
> Ops don't already have
>  * Reimplementing features, badly, over and over again in different projects 
> instead of standardizing something.
>  * More projects being created due to politics and not technical reasons.
>  * Less cross project communication
>  * Greater Operator pain at trying to assemble a more loose confederation of 
> projects into something useful.
>  * General pushing off more and more work to Operators/Users to deal with.
>  * Worse User experience as cross project issues aren't being addressed.
>  * Previously incubated projects such as Nova, Swift, etc getting a 
> disproportionate say in things as they have a greater current user base, and 
> its increasingly hard now for new projects to gain any traction.
>  * Much less community pressure on projects to work together to elevate 
> everyone. Architectural decisions are now made at individual project level 
> with little done at the OpenStack level.
>  * etc...

The thing is, all of these problems pre-date the big tent. Arguably they
were even worse before because so many projects were not only not
blessed by the TC as hard dependencies, but officially weren't even part
of OpenStack. Say what you want about the big tent, but at least we
haven't been treated to another Zaqar graduation review farce.

I think your complaint here is that the big tent hasn't done enough to
solve these problems. That's a fair complaint.

I think what you're suggesting is missing is some sort of TC imprimatur
to say that it's acceptable to take a hard dependency on a particular
project, which is effectively what graduation from incubation meant
previously (e.g. distributors were effectively, though not actually,
obliged to package it at this point if they weren't already). Of course
the only thing that can really _force_ people to adopt a project is
DefCore, and that comes with a major chicken-and-egg dilemma. It's true
that we've hollowed out most of the levels between just being "one of
us" and being DefCore-approved.

I worried about this myself at the time the big tent was proposed. But I
don't 

Re: [openstack-dev] FPGA as a dynamic nested resources

[Chris Friesen]

On 07/19/2016 01:40 PM, Ed Leafe wrote:

On Jul 19, 2016, at 11:03 AM, Roman Dobosz  wrote:


It can identified 3 levels of FPGA resources, which can be nested one
on the others:

1. Whole FPGA. If used discrete FPGA, than even today it might be pass
   through to the VM.


Can you explain why this would ever be useful? IOW, what can a VM do with an 
entire FPGA?


2. Region in FPGA. Some of the FPGA models can be divided into regions
   or slots. Also, for some model it is possible to (re)program such
   region individually - in this case there is a possibility to pass
   entire slot to the VM, so that it might be possible to reprogram
   such slot, and utilize the algorithm within the VM.


Why would a VM program the slot? Wouldn’t it usually be at the host level?


Are there no cases where a VM might want to download a proprietary program into 
an FPGA?



3. Accelerator in region/FPGA. If there is an accelerator programmed
   in the slot, it is possible, that such accelerator provides us with
   Virtual Functions (similar to the SR-IOV), than every available VF
   can be treated as a resource.


This is my understanding of what would be consumable: the slot / VF, which the 
VM could take advantage of.


4. It might be also necessary to track every VF individually, although
   I didn't assumed it will be needed, nevertheless with nested
   resources it should be easy to handle it.


I’m still not seeing the need for nesting. If you have a single FPGA with 8 
slots, when you program the slots with accelerators, you now have 8 consumable 
resources. The fact that they came from a particular FPGA unit doesn’t seem 
relevant from a scheduling perspective.


If you want to be able to provide an FPGA as either a whole un-programmed FPGA 
or as pre-programmed resources, you'd presumably need to know which whole FPGAs 
are available and which have been fractionally allocated, no?


I agree that if you are only going to have the host program the FPGA and then 
make the resources available then the scheduler doesn't need to know about whole 
FPGAs.


Chris


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

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[Wesley Hayutin]

On Tue, Jul 19, 2016 at 2:44 PM, James Slagle 
wrote:

> On Tue, Jul 12, 2016 at 3:39 PM, John Trowbridge  wrote:
> > Howdy folks,
> >
> > In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> > is being used as a CI tool in RDO. This came about organically, because
> > we needed to use RDO CI to self-gate quickstart (it relies on having a
> > baremetal virthost). It displaced another ansible based CI tool there
> > (khaleesi) and most(all?) of the extra functionality from that tool
> > (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> > roles that are able to plugin to quickstart.[1]
> >
> > We are still left with two different tool sets, where one should suffice
> > (and focus CI efforts in one place).
> >
> > I see two different ways to resolve this.
> >
> > 1. Actively work on making the tripleo-ci scripts consumable external to
> > tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> > upstream CI for packstack and puppet, so it is not totally far-fetched
> > to add support for TripleO jobs.
> >
> > Pros:
> > - All CI development just happens directly in tripleo-ci and RDO just
> > inherits that work.
> >
> > Cons:
> > - This is totally untried, and therefore a totally unknown amount of
> work.
> > - It is all or nothing in that there is no incremental path to get the
> > CI scripts working outside of CI.
> > - We have to rewrite a bunch of working ansible code in bash which IMO
> > is the wrong direction for a modern CI system.
> >
> >
> > 2. Actively work on making tripleo-ci consume the ansible work in
> > tripleo-quickstart and the external role ecosystem around it.
> >
> > Pros:
> > - This could be done incrementally, replacing a single function from
> > tripleo.sh with an invocation of tripleo-quickstart that performs that
> > function instead.
> > - We would be able to pull in a lot of extra functionality via these
> > external roles for free(ish).
> >
> > Cons:
> > - Similarly unknown amount of work to completely switch.
> > - CI development would be done in multiple repos, though each would have
> > discrete and well defined functionality.
>
> I agree we could consolidate as well. Having tripleo-ci integrated
> with ansible would probably be helpful. Some of the work I've been
> doing to support multinode jobs would benefit from being able to use
> ansible to run some setup tasks on each of the nodes as part of the
> job as well.
>
> Part of the goal of tripleo.sh was to mirror the commands in the
> documentation...that the same commands in the docs are in tripleo.sh.
> I know that has somewhat failed, but it was the goal anyway.
>
> Do you think integrating ansible into tripleo-ci changes that at all?
> tripleo-ci would be using ansible in some places, which in turn runs
> the commands (or their equivalent) that we actually document. Is the
> documentation still showing the same commands it does now, or is it
> showing running ansible as tripleo-ci would be doing?
>

Harry Rybacki and I are working on this now.  I think we have something
that is reasonable for when shell can be used and when ansible modules are
required.  I think he can make all this work public and everyone in TripleO
can keep tabs on the progress.


>
> I think I'm mostly in agreement with your #2 proposal, perhaps with
> the exception of having to rely on external roles. I don't think I
> would want to see tripleo-ci rely on ansible roles from a
> redhat-openstack organization on github.
>
> I know that we already have a lot of external dependencies in TripleO,
> and that not everything has to come from git.openstack.org. However, I
> think that we'd want to make the "source" for tripleo-ci be owned by
> the TripleO project and hosted by OpenStack infrastructure as much as
> possible. tripleo-quickstart already is, so I think it would be fine
> to start proposing some changes to tripleo-ci that use
> tripleo-quickstart to eliminate some duplication if everyone agrees
> with that. Maybe the repo-setup would be a good first iterative step.
>
> As for the external roles, I'm less of a fan of relying on these
> directly if they're not part of TripleO. I think the project should
> have ownership over how it's defined in CI to deploy/update/upgrade
> overclouds, etc.
>

+1 I think this can be handled in a couple ways depending on how many
additional git repos are acceptable to TripleO upstream.

So maybe if I provide an example this will make more sense.  I think bare
metal will work as an example.

There is a need for the code that drives CI for virt to be able to drive CI
for bare metal.  Certainly the bare metal use case will not be used nearly
as much as the virt workflow and I suspect we don't want code conflicts,
merge issues coming from the bare metal use case that may interrupt or
block the mainline virt use case.  I think TripleO still cares what the
bare metal code looks like, how it's developed, and if we can use 

Re: [openstack-dev] using feature branches, Swift's experiences

[John Dickinson]

On 19 Jul 2016, at 11:56, Dean Troyer wrote:

> On Tue, Jul 19, 2016 at 12:27 PM, John Dickinson  wrote:
>
>> Overall, using long-lived upstream feature branches has been very helpful
>> for us and overall a positive experience.
>>
>> I've seen some other teams debate and discuss using a feature branch for
>> their work but wonder about how it works. I've written down our experiences
>> with using feature branches as part of OpenStack development, including
>> some recommendations that help things go smoothly.
>>
>> https://wiki.openstack.org/wiki/Swift/feature_branches
>>
>
> Seriously nice writeup John & Swift team, thanks! I wish I had the benefit
> of that in May when I chose not to do a feature branch for OSC's impending
> major release, it would have removed the fear of the unknown from that
> choice.
>
> I am wondering if there are any corresponding bits of negative advice
> around feature branches, of the sort 'don't do X, even if it seems like a
> good idea, here is why it is not'.  This is how I see our stance on Git
> submodules for example.

I tried to add some of those in the writeup. Feature branches will start 
relatively very slowly. If you put docs at the start of a review branch, you'll 
get a *ton* of nit comments that really slow merging down. The whole fact that 
our OpenStack workflow requires (or strongly suggests) the -review branch is 
somewhat burdensome.

But overall, I really love the experience we've had with feature branches. 
Swift has been able to land seriously huge features (storage polices, erasure 
coding, and crypto) because of them, and still keep all the development in the 
open community.

Yeah, there are some hard parts, but most of that is related to other issues or 
gaps in the OpenStack community (eg tracking/planning work) and is unrelated to 
using a feature branch or not.


I'm glad you find the writeup helpful. I'd encourage all teams to consider 
feature branches for long-lived major feature development.

--John



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


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

Re: [openstack-dev] [Keystone]: Help needed with RBAC policies

[Boris Bobrov]

Also, you might need to change OS_AUTH_URL to /v3/ or to unversioned.

Policy works only with v3 api. In v2 you are either admin or user, and 
there are no policies or roles.


On 07/19/2016 10:08 PM, Boris Bobrov wrote:

Hi,

Try passing --os-identity-api-version=3 to `openstack`. Or set env
variable OS_IDENTITY_API_VERSION=3.

On 07/19/2016 09:56 PM, Nasim, Kam wrote:

Hi  folks,

I have been trying to modify the default RBAC policies in
keystone/policy.json however my policy changes don't seem to be enforced.

As a quick test, I modified the identity:list_users policy to:

"identity:list_users": "role:kam",

There is no role called "kam" defined in my deployment so I would have
expected this operation to fail.

However:

$ openstack --debug user list

+--++
| ID   | Name   |
+--++
| 3c1bd8c0f6324dcc938900d8eb801aa5 | admin  |
| 4b76763e375946998445b65b11c8db73 | ceilometer |
| 15c8e1e463cc4370ad369eaf8504b727 | cinder |
| 951068b3372f47ac827ade8f67cc19b4 | glance |
| 2b62ced877244e74ba90b546225740d0 | heat   |
| 438a24497bc8448d9ac63bf05a005796 | kam|
| 0b7af941da9b4896959f9258c6b498a0 | kam2   |
| d1c4f7a244f74892b612b9b2ded6d602 | neutron|
| 5c3ea23eb8e14070bc562951bb266073 | sysinv |
+--++

$ cat myrc
unset OS_SERVICE_TOKEN
export OS_AUTH_URL=http://192.168.204.2:5000/v2.0
export OS_ENDPOINT_TYPE=publicURL
export CINDER_ENDPOINT_TYPE=publicURL

export OS_USERNAME=admin
export OS_PASSWORD=admin
export PS1='[\u@\h \W(keystone_admin)]\$ '

export OS_TENANT_NAME=admin
export OS_REGION_NAME=RegionOne


After getting the auth token, the client uses the adminURL endpoint to
get the user list:
curl -g -i -X GET http://192.168.204.2:35357/v2.0/users -H
"User-Agent: python-keystoneclient" -H "Accept: application/json" -H
"X-Auth-Token: {SHA1}75002edfff1eb6751b3425d9d247ac3212e750f9"


Is there something I am missing here? Some specific configuration to
enable RBAC? Do admin URL ops bypass RBAC


Thanks,
Kam




__

OpenStack Development Mailing 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] [tc][all] Big tent? (Related to Plugins for all)

[Zane Bitter]

On 14/07/16 16:30, Fox, Kevin M wrote:

I'm going to go ahead and ask the difficult question now as the answer is 
relevant to the attached proposal...

Should we reconsider whether the big tent is the right approach going forward?

There have been some major downsides I think to the Big Tent approach, such as:
 * Projects not working together because of fear of adding extra dependencies 
Ops don't already have
 * Reimplementing features, badly, over and over again in different projects 
instead of standardizing something.
 * More projects being created due to politics and not technical reasons.
 * Less cross project communication
 * Greater Operator pain at trying to assemble a more loose confederation of 
projects into something useful.
 * General pushing off more and more work to Operators/Users to deal with.
 * Worse User experience as cross project issues aren't being addressed.
 * Previously incubated projects such as Nova, Swift, etc getting a 
disproportionate say in things as they have a greater current user base, and 
its increasingly hard now for new projects to gain any traction.
 * Much less community pressure on projects to work together to elevate 
everyone. Architectural decisions are now made at individual project level with 
little done at the OpenStack level.
 * etc...


The thing is, all of these problems pre-date the big tent. Arguably they 
were even worse before because so many projects were not only not 
blessed by the TC as hard dependencies, but officially weren't even part 
of OpenStack. Say what you want about the big tent, but at least we 
haven't been treated to another Zaqar graduation review farce.


I think your complaint here is that the big tent hasn't done enough to 
solve these problems. That's a fair complaint.


I think what you're suggesting is missing is some sort of TC imprimatur 
to say that it's acceptable to take a hard dependency on a particular 
project, which is effectively what graduation from incubation meant 
previously (e.g. distributors were effectively, though not actually, 
obliged to package it at this point if they weren't already). Of course 
the only thing that can really _force_ people to adopt a project is 
DefCore, and that comes with a major chicken-and-egg dilemma. It's true 
that we've hollowed out most of the levels between just being "one of 
us" and being DefCore-approved.


I worried about this myself at the time the big tent was proposed. But I 
don't think it's a silver bullet - developers of new projects have 
always been reluctant to take hard dependencies (source: first-hand 
experience starting in 2012). It's *hard* to get operators to adopt your 
project. To get operators to adopt your project plus some other project 
is... well it's definitely never easier.


That said, I don't think any of the projects you mentioned elsewhere 
(e.g. the 4 with the own implementations of guest agents) are being 
deliberately intransigent. They're each just trying to find a 
good-enough solution in isolation. If a standard way of doing guest 
agents had existed before they started then I'm confident they (we) all 
would have used it, and if one cropped up now I hope none of them would 
resist efforts to at least support it as an option (i.e. with only soft 
dependencies).


The thing that's not happening, and has never happened, is that nobody 
is getting those groups together and trying to come up with a common 
standard that everything can move toward. I think Clint's proposed 
architecture working group is a step in the right direction here. I 
don't know if such questions, which in a sense concern the user-visible 
architecture as much as the backend architecture, would be considered in 
scope (or high-priority) by that group. It's possible we might need a 
separate working group to address the needs of what I've been calling 
autonomous applications (i.e. cloud-resident applications that use the 
cloud APIs to control their own infrastructure). But I'm reluctant to 
formally propose such a thing until we have had a chance to let the 
architecture group pioneer the territory :)


cheers,
Zane.


The overall goal of the Big Tent was to make the community more inclusive. That 
I think has mostly happened. Which is good. But It also seems to have fractured 
the community more into insular islands and made the system harder for our 
operators/users. Which is bad.

Maybe the benefits outweigh the drawbacks. I'm not sure. But I think its 
probably time to consider if it has been a net positive and should be further 
refined to try and address some of these problems, or a net negative and 
different approaches be explored.

Thanks,
Kevin



__
OpenStack Development Mailing List (not for 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][all] Plugins for all

[Doug Wiegley]

> On Jul 19, 2016, at 9:36 AM, Doug Hellmann  wrote:
> 
> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
>> On 18/07/2016 17:57, Thierry Carrez wrote:
>>> Hayes, Graham wrote:
 [...]
 The point is that we were supposed to be a level field as a community
 but if we have examples like this, there is not a level playing field.
>>> 
>>> While I generally agree on your goals here (avoid special-casing some
>>> projects in generic support projects like Tempest), I want to clarify
>>> what we meant by "level playing field" in a recent resolution.
>> 
>> 
>> Yes - it has been pointed out the title is probably overloading a term
>> just used for a different purpose - I am more than willing to change it.
>> 
>> I wasn't sure where I got the name, and I realised that was probably in
>> my head from that resolution.
>> 
>>> This was meant as a level playing field for contributors within a
>>> project, not a level playing field between projects. The idea is that
>>> any contributor joining any OpenStack project should not be technically
>>> limited compared to other contributors on the same project. So, no
>>> "secret sauce" that only a subset of developers on a project have access to.
>> 
>> There is a correlation here - "special sauce" (not secret obviously)
>> that only a subset of projects have access to.
>> 
>>> I think I understand where you're gong when you say that all projects
>>> should have equal chances, but keep in mind that (1) projects should not
>>> really "compete" against each other (but rather all projects should
>>> contribute to the success of OpenStack as a whole) and (2) some
>>> OpenStack projects will always be more equal than others (for example we
>>> require that every project integrates with Keystone, and I don't see
>>> that changing).
>> 
>> Yes, I agree we should not be competing. But was should not be asking
>> the smaller projects to re-implement functionality, just because they
>> did not get integrated in time.
>> 
>> We require all projects to integrate with keystone for auth, as we
>> require all projects to integrate with neutron for network operations
>> and designate for DNS, I just see it as a requirement for using the
>> other components of OpenStack for their defined purpose.
>> 
> 
> It would be useful to have some specific information from the QA/Tempest
> team (and any others with a similar situation) about whether the current
> situation about how differences between in-tree tests and plugin tests
> are allowed to use various APIs. For example, are there APIs only
> available to in-tree tests that are going to stay that way? Or is this
> just a matter of not having had time to "harden" or "certify" or
> otherwise prepare those APIs for plugins to use them?

Doug, one example that I’m aware of — I’ve suggested moving neutron entirely 
out of devstack and into the neutron repo, via the devstack plugin interface. 
This was rejected, and the counter-argument given was that the folks that 
maintain the integrated gate, which happen to be many of the same folks 
maintaining devstack and the like, want to retain control of the items that can 
break the integrated gate, and that it gets too hard to track down individual 
project folks when the world is burning.

I don’t personally agree with the decision, but I can see some merit in that 
argument.

Thanks,
doug


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


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

Re: [openstack-dev] FPGA as a dynamic nested resources

[Ed Leafe]

On Jul 19, 2016, at 11:03 AM, Roman Dobosz  wrote:

> It can identified 3 levels of FPGA resources, which can be nested one
> on the others:
> 
> 1. Whole FPGA. If used discrete FPGA, than even today it might be pass
>   through to the VM.

Can you explain why this would ever be useful? IOW, what can a VM do with an 
entire FPGA?

> 2. Region in FPGA. Some of the FPGA models can be divided into regions
>   or slots. Also, for some model it is possible to (re)program such
>   region individually - in this case there is a possibility to pass
>   entire slot to the VM, so that it might be possible to reprogram
>   such slot, and utilize the algorithm within the VM.

Why would a VM program the slot? Wouldn’t it usually be at the host level? 

> 3. Accelerator in region/FPGA. If there is an accelerator programmed
>   in the slot, it is possible, that such accelerator provides us with
>   Virtual Functions (similar to the SR-IOV), than every available VF
>   can be treated as a resource.

This is my understanding of what would be consumable: the slot / VF, which the 
VM could take advantage of.

> 4. It might be also necessary to track every VF individually, although
>   I didn't assumed it will be needed, nevertheless with nested
>   resources it should be easy to handle it.

I’m still not seeing the need for nesting. If you have a single FPGA with 8 
slots, when you program the slots with accelerators, you now have 8 consumable 
resources. The fact that they came from a particular FPGA unit doesn’t seem 
relevant from a scheduling perspective.

-- Ed Leafe






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

Re: [openstack-dev] Mascot/logo for your project

[Michael Krotscheck]

As an aside, I'd be happy to create a project that converts any SVG logo
files into a font, for convenient usage in UI projects. Here's an example
of what that might look like: http://fontawesome.io/icons/#brand

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

Re: [openstack-dev] Barbican and Security Midcycle confirmed

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Many thanks to Fernando and IBM for setting this up!

- - Doug Mendizábal

On 7/19/16 1:49 PM, Fernando J Diaz wrote:
> Dear Barbican and Security Contributors,
> 
> It is my pleasure to announce that the Barbican and Security
> Mid-cycle meetups will be held at IBM Austin from August 15 - 19.
> 
> For more information please see
> https://etherpad.openstack.org/p/barbican-security-midcycle-N. We 
> look forward to seeing you!
> 
> Sincerely, Fernando Diaz
> 
> 
> 
> __

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

iQIcBAEBCgAGBQJXjnt5AAoJEB7Z2EQgmLX7Xy8P/iLSCKohU5g9WROg9gOUtDz4
KaVDBpSim2gxTwTw7yyqNkRk6mNODAuOp/O3AhXjcaoEp287FMyoSH4yNkxCiYa7
WMZlJ9ZoKFTCnLgSeOQF0u0xO+ZNxXfZHLc1HRHKXcq7N3hVyLOGdbvX+afYzm2m
tE93YNwyTqhM6J+yob31VKJIwclGjaAPekV6z6x92sTMP84a/s4zl0QQTrRlEAFi
eY4K8m3QP1H+n96nzfr+wJOhDs5a73eGQ/irXk1/7htgAmr9UWLwPGL3t00vk7At
unTE/l5546GaZhA8BozKpAAFWFPVz432wGLejWe9OaKEkcuRfOZGbGbi9mG8Ikam
ZXzSSU5vp92R4fXzpwLOPhqLk6KUcSJuYkRDMRMxUDcRzhubtHoQt+rU8R2its3B
bIP7v35RVAZLVEFpdTEMDpNzaS3GQexPTuxXT+xZayEhttdwd03i4wUWUGbiEJPo
zIW5LL8ltHNgn9dU1P9uqJjsCvMBsSePkUkT8M4q5Seys/IjTZ7j7Kthg0F/inje
E+wdQpOzRyDc4z151lrLqbx1W+zTQwHvjN+nnTxuW2Z9lp1kRgqX42xG//voDOVy
wHn/zcMR7lmgZ/oOw3/I5BFVhp4FeR2zJ5hxid6HwY4tJDoF1dlO9kcBP9ErfQmK
/E4nicK6GA5K4DtSri/y
=FLtR
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Keystone]: Help needed with RBAC policies

[Timothy Symanczyk]

Hi Kam,

The first thing I'd do is ensure that you're editing the correct "in use" 
policy file ( /etc/keystone/policy.json , if it's a default devstack install ). 
Secondly, a good test would be to change the actual policy to "!" (deny all). 
If that still allows anyone but the service token to do the operation, 
something beyond your specific edits is wrong.

The service token bypasses RBAC, but the admin accounts should not. Beyond 
editing the correct "in use" policy file, there should not be additional 
changes necessary to enable them.

Tim

From: "Nasim, Kam" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, July 19, 2016 at 11:56 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [Keystone]: Help needed with RBAC policies

Hi  folks,

I have been trying to modify the default RBAC policies in keystone/policy.json 
however my policy changes don't seem to be enforced.

As a quick test, I modified the identity:list_users policy to:

"identity:list_users": "role:kam",

There is no role called "kam" defined in my deployment so I would have expected 
this operation to fail.

However:

$ openstack --debug user list

+--++
| ID   | Name   |
+--++
| 3c1bd8c0f6324dcc938900d8eb801aa5 | admin  |
| 4b76763e375946998445b65b11c8db73 | ceilometer |
| 15c8e1e463cc4370ad369eaf8504b727 | cinder |
| 951068b3372f47ac827ade8f67cc19b4 | glance |
| 2b62ced877244e74ba90b546225740d0 | heat   |
| 438a24497bc8448d9ac63bf05a005796 | kam|
| 0b7af941da9b4896959f9258c6b498a0 | kam2   |
| d1c4f7a244f74892b612b9b2ded6d602 | neutron|
| 5c3ea23eb8e14070bc562951bb266073 | sysinv |
+--++

$ cat myrc
unset OS_SERVICE_TOKEN
export OS_AUTH_URL=http://192.168.204.2:5000/v2.0
export OS_ENDPOINT_TYPE=publicURL
export CINDER_ENDPOINT_TYPE=publicURL

export OS_USERNAME=admin
export OS_PASSWORD=admin
export PS1='[\u@\h \W(keystone_admin)]\$ '

export OS_TENANT_NAME=admin
export OS_REGION_NAME=RegionOne


After getting the auth token, the client uses the adminURL endpoint to get the 
user list:
curl -g -i -X GET http://192.168.204.2:35357/v2.0/users -H "User-Agent: 
python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}75002edfff1eb6751b3425d9d247ac3212e750f9"


Is there something I am missing here? Some specific configuration to enable 
RBAC? Do admin URL ops bypass RBAC


Thanks,
Kam

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

Re: [openstack-dev] [Keystone]: Help needed with RBAC policies

[Boris Bobrov]

Hi,

Try passing --os-identity-api-version=3 to `openstack`. Or set env 
variable OS_IDENTITY_API_VERSION=3.


On 07/19/2016 09:56 PM, Nasim, Kam wrote:

Hi  folks,

I have been trying to modify the default RBAC policies in keystone/policy.json 
however my policy changes don't seem to be enforced.

As a quick test, I modified the identity:list_users policy to:

"identity:list_users": "role:kam",

There is no role called "kam" defined in my deployment so I would have expected 
this operation to fail.

However:

$ openstack --debug user list

+--++
| ID   | Name   |
+--++
| 3c1bd8c0f6324dcc938900d8eb801aa5 | admin  |
| 4b76763e375946998445b65b11c8db73 | ceilometer |
| 15c8e1e463cc4370ad369eaf8504b727 | cinder |
| 951068b3372f47ac827ade8f67cc19b4 | glance |
| 2b62ced877244e74ba90b546225740d0 | heat   |
| 438a24497bc8448d9ac63bf05a005796 | kam|
| 0b7af941da9b4896959f9258c6b498a0 | kam2   |
| d1c4f7a244f74892b612b9b2ded6d602 | neutron|
| 5c3ea23eb8e14070bc562951bb266073 | sysinv |
+--++

$ cat myrc
unset OS_SERVICE_TOKEN
export OS_AUTH_URL=http://192.168.204.2:5000/v2.0
export OS_ENDPOINT_TYPE=publicURL
export CINDER_ENDPOINT_TYPE=publicURL

export OS_USERNAME=admin
export OS_PASSWORD=admin
export PS1='[\u@\h \W(keystone_admin)]\$ '

export OS_TENANT_NAME=admin
export OS_REGION_NAME=RegionOne


After getting the auth token, the client uses the adminURL endpoint to get the 
user list:
curl -g -i -X GET http://192.168.204.2:35357/v2.0/users -H "User-Agent: python-keystoneclient" -H 
"Accept: application/json" -H "X-Auth-Token: 
{SHA1}75002edfff1eb6751b3425d9d247ac3212e750f9"


Is there something I am missing here? Some specific configuration to enable 
RBAC? Do admin URL ops bypass RBAC


Thanks,
Kam




__
OpenStack Development Mailing 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] [ovs-dev] SFC-Summary: MultiTenant

[Cathy Zhang]

Hi Russell,

Please see inline.

Thanks,
Cathy

From: Russell Bryant [mailto:russ...@ovn.org]
Sent: Tuesday, July 19, 2016 6:51 AM
To: Cathy Zhang
Cc: Farhad Sunavala; d...@openvswitch.org; Russell Bryant; Kyle Mestery
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant

Even putting the multi-tenant considerations aside, I think sub-ports (tagging 
or encapsulation) are valuable as a mechanism to differentiate between 
different chains (traffic matched with different classifiers).
Cathy> Definitely. Using virtual sub-ports to differentiate different chains 
will greatly improve the OVS performance since this eliminates the need for 
re-classification at each hop. It also solves the problem caused by “some 
SF/VNF could change the 5-tuple or n-tuple fields of the packets that are used 
for chain flow classification”.  Based on info from John of Palo Alto networks, 
their VNF is alreadt using different virtual ports to differentiate different 
chains.

I agree that it's also complex that it requires coordination with the VNF - 
both with the vendors and a mechanism to coordinate with VNFs at runtime.

Cathy> The correlation between the sub-port and the chain needs to be 
communicated to the OVS as well as to the VNF. Networking-sfc’s chain API 
already has this info and passes this info down to the driver and OVS. The same 
information can be passed to VNF Manager which in turn passes to VNF. But as 
you said, we need coordination with the VNF manager. Different vendors could 
have different VNF managers. We need some agreement there.

I'd really like to understand better what people building VNFs are doing and 
what they want.  So many SFC conversations feel like vendors trying to guess.  
I haven't actually talked to any users myself.  I just want to build what 
people will actually use.  :-)

Cathy> There are many different types of VNFs. Some VNFs could have a need for 
passing of some metadata to the next hop VNF. I would also like to hear more 
use cases☺

On Wed, Jul 13, 2016 at 6:18 PM, Cathy Zhang 
> wrote:
Hi Russell,

To add on Farhad's point, with current neutron and nova, we cannot create a 
multi-tenant  VNF.
Currently, nova checks whether the neutron port belongs to the same tenant as 
the VM itself.
You attach a network interface (neutron port) to a VM using nova 
interface-attach, if the port and the VM are in different tenants, an error is 
given.

As to the sub-ports feature of Neutron, although it allows the sub-ports to 
associate with different networks, it seems these networks need to all belong 
to the same tenant according to vlan-aware-vms spec 
http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html.

It is not clear whether it can work properly if these networks belong to 
different tenants.
DO you know this? We may need to send an email to Neutron team for 
clarification on this.

Thanks,
Cathy

-Original Message-
From: dev 
[mailto:dev-boun...@openvswitch.org] On 
Behalf Of Farhad Sunavala
Sent: Tuesday, July 12, 2016 7:59 PM
To: d...@openvswitch.org
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant

>I was thinking this could be handled with child / sub-ports.  We do
>this today for containers in VMs.  We can have a single VIF for a VM
>that is connected to multiple networks that are owned by separate
>tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
>would be used to differentiate the traffic for each networking in/out
>of that VIF.  I had started adding the ability to use MPLS for this in
>my prototype for this reason, as that was what networking-sfc had defined.
I have a quick question on the above. (multi-tenancy).Yes, I know the 
containers can be in different networks of the same tenant.How does it work 
when the containers are in different tenants ?
Below is the latest spec for vlan-aware-vms 
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html

The trick is to create neutron ports (for the subports) and then link them to 
the trunk port using neutron trunk-subport-add TRUNK \   
PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]

In the above command all the neutron ports (trunk  ports and subports) must be 
in the same tenant.As far as I know, a tenant will not see neutron ports from 
another tenant.Or will this command allow neutron ports from different 
tenants to be attached ?
E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1 
(network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The 
trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The 
above command will be neutron trunk-subport-add T1 \   A  vlan 1 \   B 
vlan 2 Is my understanding correct? thanks,Farhad.
___
dev mailing list
d...@openvswitch.org

Re: [openstack-dev] using feature branches, Swift's experiences

[Dean Troyer]

On Tue, Jul 19, 2016 at 12:27 PM, John Dickinson  wrote:

> Overall, using long-lived upstream feature branches has been very helpful
> for us and overall a positive experience.
>
> I've seen some other teams debate and discuss using a feature branch for
> their work but wonder about how it works. I've written down our experiences
> with using feature branches as part of OpenStack development, including
> some recommendations that help things go smoothly.
>
> https://wiki.openstack.org/wiki/Swift/feature_branches
>

Seriously nice writeup John & Swift team, thanks! I wish I had the benefit
of that in May when I chose not to do a feature branch for OSC's impending
major release, it would have removed the fear of the unknown from that
choice.

I am wondering if there are any corresponding bits of negative advice
around feature branches, of the sort 'don't do X, even if it seems like a
good idea, here is why it is not'.  This is how I see our stance on Git
submodules for example.

dt

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

[openstack-dev] [Keystone]: Help needed with RBAC policies

[Nasim, Kam]

Hi  folks,

I have been trying to modify the default RBAC policies in keystone/policy.json 
however my policy changes don't seem to be enforced.

As a quick test, I modified the identity:list_users policy to:

"identity:list_users": "role:kam",

There is no role called "kam" defined in my deployment so I would have expected 
this operation to fail.

However:

$ openstack --debug user list

+--++
| ID   | Name   |
+--++
| 3c1bd8c0f6324dcc938900d8eb801aa5 | admin  |
| 4b76763e375946998445b65b11c8db73 | ceilometer |
| 15c8e1e463cc4370ad369eaf8504b727 | cinder |
| 951068b3372f47ac827ade8f67cc19b4 | glance |
| 2b62ced877244e74ba90b546225740d0 | heat   |
| 438a24497bc8448d9ac63bf05a005796 | kam|
| 0b7af941da9b4896959f9258c6b498a0 | kam2   |
| d1c4f7a244f74892b612b9b2ded6d602 | neutron|
| 5c3ea23eb8e14070bc562951bb266073 | sysinv |
+--++

$ cat myrc
unset OS_SERVICE_TOKEN
export OS_AUTH_URL=http://192.168.204.2:5000/v2.0
export OS_ENDPOINT_TYPE=publicURL
export CINDER_ENDPOINT_TYPE=publicURL

export OS_USERNAME=admin
export OS_PASSWORD=admin
export PS1='[\u@\h \W(keystone_admin)]\$ '

export OS_TENANT_NAME=admin
export OS_REGION_NAME=RegionOne


After getting the auth token, the client uses the adminURL endpoint to get the 
user list:
curl -g -i -X GET http://192.168.204.2:35357/v2.0/users -H "User-Agent: 
python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}75002edfff1eb6751b3425d9d247ac3212e750f9"


Is there something I am missing here? Some specific configuration to enable 
RBAC? Do admin URL ops bypass RBAC


Thanks,
Kam

__
OpenStack Development Mailing 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] Barbican and Security Midcycle confirmed

[Fernando J Diaz]

Dear Barbican and Security Contributors,
 
It is my pleasure to announce that the Barbican and Security Mid-cycle meetups will be held at IBM Austin from August 15 - 19.
 
For more information please see https://etherpad.openstack.org/p/barbican-security-midcycle-N. We look forward to seeing you!
 
Sincerely,
Fernando Diaz


__
OpenStack Development Mailing 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] Barbican and Security Midcycle confirmed

[Fernando J Diaz]

Dear Barbican and Security Contributors,
 
It is my pleasure to announce that the Barbican and Security Mid-cycle meetups will be held at IBM Austin from August 15 - 19.
 
For more information please see https://etherpad.openstack.org/p/barbican-security-midcycle-N. We look forward to seeing you!
 
Sincerely,
Fernando Diaz


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

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[James Slagle]

On Tue, Jul 12, 2016 at 3:39 PM, John Trowbridge  wrote:
> Howdy folks,
>
> In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> is being used as a CI tool in RDO. This came about organically, because
> we needed to use RDO CI to self-gate quickstart (it relies on having a
> baremetal virthost). It displaced another ansible based CI tool there
> (khaleesi) and most(all?) of the extra functionality from that tool
> (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> roles that are able to plugin to quickstart.[1]
>
> We are still left with two different tool sets, where one should suffice
> (and focus CI efforts in one place).
>
> I see two different ways to resolve this.
>
> 1. Actively work on making the tripleo-ci scripts consumable external to
> tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> upstream CI for packstack and puppet, so it is not totally far-fetched
> to add support for TripleO jobs.
>
> Pros:
> - All CI development just happens directly in tripleo-ci and RDO just
> inherits that work.
>
> Cons:
> - This is totally untried, and therefore a totally unknown amount of work.
> - It is all or nothing in that there is no incremental path to get the
> CI scripts working outside of CI.
> - We have to rewrite a bunch of working ansible code in bash which IMO
> is the wrong direction for a modern CI system.
>
>
> 2. Actively work on making tripleo-ci consume the ansible work in
> tripleo-quickstart and the external role ecosystem around it.
>
> Pros:
> - This could be done incrementally, replacing a single function from
> tripleo.sh with an invocation of tripleo-quickstart that performs that
> function instead.
> - We would be able to pull in a lot of extra functionality via these
> external roles for free(ish).
>
> Cons:
> - Similarly unknown amount of work to completely switch.
> - CI development would be done in multiple repos, though each would have
> discrete and well defined functionality.

I agree we could consolidate as well. Having tripleo-ci integrated
with ansible would probably be helpful. Some of the work I've been
doing to support multinode jobs would benefit from being able to use
ansible to run some setup tasks on each of the nodes as part of the
job as well.

Part of the goal of tripleo.sh was to mirror the commands in the
documentation...that the same commands in the docs are in tripleo.sh.
I know that has somewhat failed, but it was the goal anyway.

Do you think integrating ansible into tripleo-ci changes that at all?
tripleo-ci would be using ansible in some places, which in turn runs
the commands (or their equivalent) that we actually document. Is the
documentation still showing the same commands it does now, or is it
showing running ansible as tripleo-ci would be doing?

I think I'm mostly in agreement with your #2 proposal, perhaps with
the exception of having to rely on external roles. I don't think I
would want to see tripleo-ci rely on ansible roles from a
redhat-openstack organization on github.

I know that we already have a lot of external dependencies in TripleO,
and that not everything has to come from git.openstack.org. However, I
think that we'd want to make the "source" for tripleo-ci be owned by
the TripleO project and hosted by OpenStack infrastructure as much as
possible. tripleo-quickstart already is, so I think it would be fine
to start proposing some changes to tripleo-ci that use
tripleo-quickstart to eliminate some duplication if everyone agrees
with that. Maybe the repo-setup would be a good first iterative step.

As for the external roles, I'm less of a fan of relying on these
directly if they're not part of TripleO. I think the project should
have ownership over how it's defined in CI to deploy/update/upgrade
overclouds, etc.

Are the roles generic enough that we could propose these as part of
TripleO directly as new repos, and is there interest in doing that?

-- 
-- James Slagle
--

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

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Clint Byrum]

Excerpts from Julien Danjou's message of 2016-07-19 09:30:36 +0200:
> On Mon, Jul 18 2016, Joshua Harlow wrote:
> 
> > Thus why I think the starting of the architecture working group is a good
> > thing; because I have a believe that people are forgetting among all of this
> > that such a group holds a lot of the keys to the kingdom (whether u, the
> > reader, want to admit that or not is well the readers problem) in openstack
> > (sorry and no disrespect to independent folks & contributors), but most of 
> > us
> > work for large companies that have architects (and leads) and if those
> > architects (and leads) can get together cross-company to aggregate and 
> > (agree
> > on) and solve actual problems then that really is IMHO the only way to keep 
> > our
> > projects healthy (assuming we can even do that at this stage).
> 
> I think it is a bit naive to think any working group is going to fix
> architectural problems. You know first hand what happened¹ with the Nova
> service group and tooz for example.
> 

Perhaps if we form and start working together as a group, we can disect
why nothing happened, build consensus on the most important thing to do
next, and actually fix some architectural problems. The social structure
that teams have is a huge part of the deadlock we find ourselves in
with certain controversial changes. The idea is to unroll the dependency
loop and start _somewhere_ rather than where a lot of these efforts die:
starting _everywhere_.

__
OpenStack Development Mailing List (not for 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][all] Big tent? (Related to Plugins for all)

[Fox, Kevin M]

+1.

I think there have been a few efforts around the issue of the small tent thing 
described below, such as the http://www.openstack.org/brand/interop/ effort.

But those profiles seemed centred around standardizing the minimal common 
denominator parts of what's widely deployed today rather then coming up with a 
new standard for the pieces that should be required for a next generation 
iteration of the system. Without the latter, we just keep the same old stuff in 
the small tent, and no new stuff gets added.

Thanks,
Kevin

From: Ed Leafe [e...@leafe.com]
Sent: Monday, July 18, 2016 9:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On Jul 18, 2016, at 12:39 PM, Fox, Kevin M  wrote:

> I'm arguing the opposite. It should be a requirement to use the OpenStack 
> Secret Store.
>
> Instead, we're trying to make it optional and either reimplementing large 
> swaths of it in individual projects to make it optional, or skip security all 
> together.
>
> If it wasn't optional, then:
> * Keystone could rely on it being there for password hashing
> * Magnum can rely on it for security.
> * lbaas can rely on it
> * App developers can rely on it being there
> * ...
>
> Same with Zaqar. It was a requirement then,
> * Guest agents of heat, sahara, mangum, trove, etc could all rely on it being 
> there and wouldn't have to deal with workarounds
> * Horizon could rely on it being there for dynamic ui
> * App developers can rely on it being there.
>
> Yes, it seems like more work for an operator to have to install "one more 
> thing", but the savings it provides by not having to do that "one more thing" 
> in 7 different projects pays for it.

There is a lot to be said for code simplification. When Glance split out of 
Nova, the knowledge that Glance would be required to be there meant the the 
code in Nova for interacting with it didn’t have to contain tons of ‘if :  else ”. Knowing that that code was 
unnecessary made writing the interaction much simpler (and less tedious to 
read). So if we added, say, Barbican as a requirement, all of the other 
projects that need to handle secrets (a lot of them!) could simply program to 
the Barbican interface, and be done with it.

The discussion of whether project X should be required is a whole ‘nother 
topic. But I want to emphasize that often the utility of having a standard is 
grossly underestimated.

In this discussion, the issue that seems to be arising is that the Big Tent 
doesn’t provide for a path for a project to be reconsidered as an OpenStack 
standard, in the way that Nova and Glance and Swift are. The Small Tent 
“incubation” process designed to identify which projects were mature enough to 
be considered “one of us”, when “us” was the group of core projects. This was 
unnecessarily harsh, and pushed away many worthy efforts. In an attempt to 
improve this, the definition of “one of us” was broadened so that lots of 
interesting projects could be part of the community.

What I think is causing some confusion (and friction) is that OpenStack needs 
two “us”s: what projects are part of our ecosystem and build software in the 
same open way (the Big Tent concept), and which are a fundamental component of 
the overall OpenStack software, which all other projects can assume are 
available (the Small Tent concept).

To that end, it seems necessary to define a migration path for a project to 
become required. Of course, most will never need to be required, but I think a 
case could be made that several projects (Barbican and Zaqar are the obvious 
ones here) have matured to the point where it makes sense to standardize on 
them. They are mature, and no other projects have come along to challenge their 
designs. At some point, it makes sense to stop pretending that there are 
options, and establish a standard instead.


-- Ed Leafe






__
OpenStack Development Mailing 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] [E] [TripleO] CI Driven Documentation: Design Discussion

[Harry Rybacki]

On Tue, Jul 19, 2016 at 1:44 PM, Gordon, Kent
 wrote:
> How do I access  item [1]?
>
> [1] - http://rdo-ci-cd.etherpad.corp.redhat.com/weekly-scrum
> rdo-ci-cd.etherpad.corp.redhat.com  does not have a valid DNS entry.
>
Good catch. In short you can't. Our team is in the transition to
upstream focus -- will need to move our minutes to a new etherpad.
Relevant snippet below:

Demo: Harry Rybacki, creating tripleo-doc from CI
  Trown's PoC Review (redhat-openstack/tripleo-quickstart):
https://review.gerrithub.io/#/c/261218/
  Tracking card:
https://trello.com/c/whHpxvkO/269-investigate-ci-automated-documentation
  Prototyping role: https://github.com/HarryRybacki/tripleo-documentor

>
> Kent S. Gordon
> Verizon Wireless
>
> -Original Message-
> From: Harry Rybacki [mailto:hryba...@redhat.com]
> Sent: Tuesday, July 19, 2016 10:34 AM
> To: openstack-dev@lists.openstack.org
> Subject: [E] [openstack-dev] [TripleO] CI Driven Documentation: Design 
> Discussion
>
> All,
>
> During today's rdo-ci scrum[1], I briefed the team on PoC work that will 
> bring trown's old PoC[2] review inline with the current state of affairs of 
> TripleO-Quickstart (OOOQS) and related ansible roles used heavily in upstream 
> CI[3].
>
> To summarize, our goal is to leverage the power Sphinx[4] and templated bash 
> scripts[5] generated during jobs to decrease the overhead of maintaining 
> TripleO docs. Additionally, we aim to provide more build specific e.g., this 
> is how you would do a minimal deployment on [centos|rhelx|...], documentation 
> with as much automation as possible.
>
> In trown's initial PoC[2] conditionals are used to inside of the templates to 
> allow for selective addition of RST blocks and removal of non-useful chunks 
> of code (CI specific) for documentation[6]. The resulting docs are quite 
> aesthetically pleasing[7]. The multitude of roles which are now consumed for 
> any given build and used by OOOQS complicates things a bit.
>
> Regardless of how we move forward, roles, such as tripleo-undercloud-post[8], 
> will have to update their relevant bash templates[9].
>
> Two ideas were discussed:
>
> 1. Minimally modify the templates to have inline comments which would equate 
> to "steps" which can then be followed to reproduce a build.
>   - This would require the least work bringing roles up to speed but would in 
> turn lose the ability to use much of RST's power.
>   - This would make automated documentation incredibly easy -- just pull 
> relevant bash scripts off of the LastSuccessfullBuild from the artifacts 
> server for a given job every XX hours and
>
> 2. Modify the templates to conditionally add snippets as noted in the 
> original PoC[6].
>   - This would provide the ability to have highly customizable documentation 
> and all of the givens from using RST
>   - This would require executing roles twice (once for the build and once for 
> producing the documentation version of the scripts used during the build).
> - Other problem areas could result from this. For example, vars set 
> dynamically during a roles execution during the initial build might not be 
> available (or different) during the second execution.
>
> While I think that we should strive to have the flexibility RST provides us, 
> the MVP (option 1) already gives us (and our users) a huge leg up already 
> with continually up-to-date documentation that has been tested (and built by) 
> our CI.
>
> Any thoughts on the above would be greatly appreciated  -- perhaps there is a 
> clean way to generate two sets of templated bash in tandem and we can just 
> pull the documentation version off of the artifacts server?
>
> [1] - http://rdo-ci-cd.etherpad.corp.redhat.com/weekly-scrum
> [2] - https://review.gerrithub.io/#/c/261218/
> [3] - https://github.com/HarryRybacki/tripleo-documentor
> [4] - http://www.sphinx-doc.org/en/stable/
> [5] - 
> https://github.com/openstack/tripleo-quickstart/tree/master/roles/tripleo/undercloud/templates
> [6] - 
> https://review.gerrithub.io/#/c/261218/1/playbooks/roles/images/undercloud/templates/undercloud-run
> [7] - https://trown.fedorapeople.org/rdodocgen/
> [8] - https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post
> [9] - 
> https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post/blob/master/templates/undercloud-install-post.sh.j2
>
> Thanks, all!
>
>
> /R
>
> Harry Rybacki
> Software Engineer, Red Hat
>
> __
> OpenStack Development Mailing 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] [Magnum] Does Docker-Swarm not support inter-node/vm inter-container networking ?

[Waines, Greg]

I have successfully setup devstack with Magnum,
following this link 
https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst#building-and-using-a-swarm-bay

I created a Docker-Swarm bay and successfully launched some simple containers.

I noticed that Docker-Swarm’s Container Networking Solution seems to simply be 
an SNAT on its swarm-node VM.
And noticed that Docker-Swarm assigns the same Container subnet to each 
swarm-node VM … and re-uses Container IP Addresses from this subnet across 
swarm-node VMs.

Given this … it does not appear that Docker-Swarm can support networking 
between two containers on different swarm-node VMs.
Is this True ?
OR
Is there a configuration option, thru Magnum or Docker-Swarm to enable this 
inter-node inter-container Networking ?

Greg.

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

[openstack-dev] FPGA as a dynamic nested resources

[Roman Dobosz]

Hi all,

Some time ago Jay Pipes published etherpad[1] with ideas around
modelling nested resources, taking NUMA as an example. I was also
encouraged ;) to start this thread, on last Nova scheduler meeting.

I was read mentioned etherpad and what hits me was that described
scenario with NUMA cells resembles the way how FPGA can be managed. In
some extent.

NUMA cell can be treated as a vessel for memory cells, and it is
expressed as number of MB. So it is possible to extract the
information from existing data and add another level of aggregation
using only clever prepared SQL query.

I think, that problem might be broader, than using existing, tweaked a
bit model. If we take a look into resources, which FPGA may expose,
than it can be couple of levels, and each of them can be treated as
resource.

It can identified 3 levels of FPGA resources, which can be nested one
on the others:

1. Whole FPGA. If used discrete FPGA, than even today it might be pass
   through to the VM.

2. Region in FPGA. Some of the FPGA models can be divided into regions
   or slots. Also, for some model it is possible to (re)program such
   region individually - in this case there is a possibility to pass
   entire slot to the VM, so that it might be possible to reprogram
   such slot, and utilize the algorithm within the VM.

3. Accelerator in region/FPGA. If there is an accelerator programmed
   in the slot, it is possible, that such accelerator provides us with
   Virtual Functions (similar to the SR-IOV), than every available VF
   can be treated as a resource.

4. It might be also necessary to track every VF individually, although
   I didn't assumed it will be needed, nevertheless with nested
   resources it should be easy to handle it.

Correlation between such resources are a bit different from NUMA -
while in NUMA case there is a possibility to either schedule a VM with
some memory specified, or request memory within NUMA cell, in FPGA if
there is slot taken, or accelerator already programmed and used, there
is no way to offer FPGA as a whole to the tenant, until all
accelerators and slots are free.

I've followed Jay idea about nested resources and having in mind
blueprint[2] regarding dynamic resources I've prepared how it fit in.

Tables are unchanged - it is a copy-paste from the etherpad[1]:


CREATE TABLE resource_providers (
id INT NOT NULL AUTOINCREMENT PRIMARY KEY,
uuid CHAR(36) NOT NULL,
name VARCHAR(100) NULL,
root_provider_id INT NULL,
parent_provider_id INT NULL
);

CREATE TABLE inventories (
id INT NOT NULL AUTOINCREMENT PRIMARY KEY,
resource_provider_id INT NOT NULL,
resource_class_id INT NOT NULL,
total INT NOT NULL,
reserved INT NOT NULL,
min_unit INT NOT NULL,
max_unit INT NOT NULL,
step_size INT NOT NULL,
allocation_ratio INT NOT NULL
);

CREATE TABLE allocations (
id INT NOT NULL AUTOINCREMENT PRIMARY KEY,
resource_provider_id INT NOT NULL,
consumer_uuid CHAR(36) NOT NULL,
resource_class_id INT NOT NULL,
used INT NOT NULL
);


Than lets fill the tables with data of following structure:

-- FPGA-1
--   +- FPGA-1 slot1 (taken), resource_provider_id:
--   +- FPGA-1 slot2
--   +- FPGA-1 slot2 acceleratorX
--   +- FPGA-1 slot2 acceleratorX VF1 (taken)
--   +- FPGA-1 slot2 acceleratorX VF2 (taken)
--   +- FPGA-1 slot2 acceleratorX VF3 (taken)
--   +- FPGA-1 slot2 acceleratorX VF4 (taken)
--   +- FPGA-1 slot2 acceleratorX VF5
--   +- ..
--   +- FPGA-1 slot2 acceleratorX VF32
--   +- FPGA-1 slot3
-- FPGA-2
--   +- FPGA-2 slot1

where FPGA-1 and FPGA-2 are hosts with FPGA on board. There is also
assumed, that new dynamic resources are created: id 1666 means 'FPGA'
(although it might be simply standard class, which will be hardcoded
ENUM), 1667 means 'FPGA slot' and 1668 'FPGA accelerator'.


INSERT INTO resource_providers VALUES
(1, '', 'FPGA-1', 1, NULL),
(2, '', 'FPGA-1 slot 1', 1, 1),
(3, '', 'FPGA-1 slot 2', 1, 1),
(4, '', 'FPGA-1 slot 3', 1, 1),
(5, '', 'FPGA-1 slot 2 acceleratorX', 1, 3),
(6, '', 'FPGA-2', 6, NULL),
(7, '', 'FPGA-2 slot', 6, 6);


INSERT INTO inventories VALUES
(1, 1, 1666, 1, 0, 1, 1, 1, 1.0),
(2, 2, 1667, 1, 0, 1, 1, 1, 1.0),
(3, 3, 1667, 1, 0, 1, 1, 1, 1.0),
(4, 4, 1667, 1, 0, 1, 1, 1, 1.0),
(5, 5, 1668, 32, 0, 1, 32, 1, 1.0),
(6, 6, 1666, 1, 0, 1, 1, 1, 1.0),
(7, 7, 1667, 1, 0, 1, 1, 1, 1.0);

INSERT INTO allocations VALUES
(1, 5, '', 1668, 4),
(2, 2, '', 1667, 1);


To get id of resource of type acceleratorX to allocate 8 VF:


SELECT rp.id
FROM resource_providers rp
LEFT JOIN allocations al ON al.resource_provider_id = rp.id
LEFT JOIN inventories iv ON iv.resource_provider_id = rp.id
WHERE al.resource_class_id = 1668
AND (iv.total - COALESCE(al.used, 0)) >= 8;


Note, that I don't have to calculate number of total available VFs in
this case, although it might happen, that user might schedule VM which
requests number of VFs that exceed available VFs 

Re: [openstack-dev] [E] [TripleO] CI Driven Documentation: Design Discussion

[Gordon, Kent]

How do I access  item [1]?

[1] - http://rdo-ci-cd.etherpad.corp.redhat.com/weekly-scrum
rdo-ci-cd.etherpad.corp.redhat.com  does not have a valid DNS entry.


Kent S. Gordon
Verizon Wireless

-Original Message-
From: Harry Rybacki [mailto:hryba...@redhat.com] 
Sent: Tuesday, July 19, 2016 10:34 AM
To: openstack-dev@lists.openstack.org
Subject: [E] [openstack-dev] [TripleO] CI Driven Documentation: Design 
Discussion

All,

During today's rdo-ci scrum[1], I briefed the team on PoC work that will bring 
trown's old PoC[2] review inline with the current state of affairs of 
TripleO-Quickstart (OOOQS) and related ansible roles used heavily in upstream 
CI[3].

To summarize, our goal is to leverage the power Sphinx[4] and templated bash 
scripts[5] generated during jobs to decrease the overhead of maintaining 
TripleO docs. Additionally, we aim to provide more build specific e.g., this is 
how you would do a minimal deployment on [centos|rhelx|...], documentation with 
as much automation as possible.

In trown's initial PoC[2] conditionals are used to inside of the templates to 
allow for selective addition of RST blocks and removal of non-useful chunks of 
code (CI specific) for documentation[6]. The resulting docs are quite 
aesthetically pleasing[7]. The multitude of roles which are now consumed for 
any given build and used by OOOQS complicates things a bit.

Regardless of how we move forward, roles, such as tripleo-undercloud-post[8], 
will have to update their relevant bash templates[9].

Two ideas were discussed:

1. Minimally modify the templates to have inline comments which would equate to 
"steps" which can then be followed to reproduce a build.
  - This would require the least work bringing roles up to speed but would in 
turn lose the ability to use much of RST's power.
  - This would make automated documentation incredibly easy -- just pull 
relevant bash scripts off of the LastSuccessfullBuild from the artifacts server 
for a given job every XX hours and

2. Modify the templates to conditionally add snippets as noted in the original 
PoC[6].
  - This would provide the ability to have highly customizable documentation 
and all of the givens from using RST
  - This would require executing roles twice (once for the build and once for 
producing the documentation version of the scripts used during the build).
- Other problem areas could result from this. For example, vars set 
dynamically during a roles execution during the initial build might not be 
available (or different) during the second execution.

While I think that we should strive to have the flexibility RST provides us, 
the MVP (option 1) already gives us (and our users) a huge leg up already with 
continually up-to-date documentation that has been tested (and built by) our CI.

Any thoughts on the above would be greatly appreciated  -- perhaps there is a 
clean way to generate two sets of templated bash in tandem and we can just pull 
the documentation version off of the artifacts server?

[1] - http://rdo-ci-cd.etherpad.corp.redhat.com/weekly-scrum
[2] - https://review.gerrithub.io/#/c/261218/
[3] - https://github.com/HarryRybacki/tripleo-documentor
[4] - http://www.sphinx-doc.org/en/stable/
[5] - 
https://github.com/openstack/tripleo-quickstart/tree/master/roles/tripleo/undercloud/templates
[6] - 
https://review.gerrithub.io/#/c/261218/1/playbooks/roles/images/undercloud/templates/undercloud-run
[7] - https://trown.fedorapeople.org/rdodocgen/
[8] - https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post
[9] - 
https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post/blob/master/templates/undercloud-install-post.sh.j2

Thanks, all!


/R

Harry Rybacki
Software Engineer, Red Hat

__
OpenStack Development Mailing 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] [tc][all] Plugins for all

[John Dickinson]

I've been trying to follow this thread, but I'll admit I'm confused about what 
is being asked about or proposed. I'm not sure what "plugins for all" means.

Is "plugins for all" a way to make every plugin in an OpenStack project work 
the same way? How would that work? There's a huge set of diversity in the kind 
of things that plugins are used for, so I can't really imagine how there is a 
common subset that can be used everywhere.

Is "plugins for all" a way to say that every OpenStack project should have a 
stable API and that's the *only* way to talk to it (i.e. zero knowledge of 
internal state or design)? I think that's a really good idea that is vital to 
the future of OpenStack.

Is "plugins for all" a way to say that there is a set of functionality that is 
guaranteed to be there, eg with Neutron for networking or Trove for DBs, and if 
a project uses that functionality it must use the right OpenStack project?

I've picked up on elements of all three of these goals throughout the thread, 
but I'm not sure what's right or if I'm completely missing it.

Please help!

--John




On 19 Jul 2016, at 9:59, Hayes, Graham wrote:

> On 19/07/2016 16:39, Doug Hellmann wrote:
>> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
>>> On 18/07/2016 17:57, Thierry Carrez wrote:
 Hayes, Graham wrote:
> [...]
> The point is that we were supposed to be a level field as a community
> but if we have examples like this, there is not a level playing field.

 While I generally agree on your goals here (avoid special-casing some
 projects in generic support projects like Tempest), I want to clarify
 what we meant by "level playing field" in a recent resolution.
>>>
>>>
>>> Yes - it has been pointed out the title is probably overloading a term
>>> just used for a different purpose - I am more than willing to change it.
>>>
>>> I wasn't sure where I got the name, and I realised that was probably in
>>> my head from that resolution.
>>>
 This was meant as a level playing field for contributors within a
 project, not a level playing field between projects. The idea is that
 any contributor joining any OpenStack project should not be technically
 limited compared to other contributors on the same project. So, no
 "secret sauce" that only a subset of developers on a project have access 
 to.
>>>
>>> There is a correlation here - "special sauce" (not secret obviously)
>>> that only a subset of projects have access to.
>>>
 I think I understand where you're gong when you say that all projects
 should have equal chances, but keep in mind that (1) projects should not
 really "compete" against each other (but rather all projects should
 contribute to the success of OpenStack as a whole) and (2) some
 OpenStack projects will always be more equal than others (for example we
 require that every project integrates with Keystone, and I don't see
 that changing).
>>>
>>> Yes, I agree we should not be competing. But was should not be asking
>>> the smaller projects to re-implement functionality, just because they
>>> did not get integrated in time.
>>>
>>> We require all projects to integrate with keystone for auth, as we
>>> require all projects to integrate with neutron for network operations
>>> and designate for DNS, I just see it as a requirement for using the
>>> other components of OpenStack for their defined purpose.
>>>
>>
>> It would be useful to have some specific information from the QA/Tempest
>> team (and any others with a similar situation) about whether the current
>> situation about how differences between in-tree tests and plugin tests
>> are allowed to use various APIs. For example, are there APIs only
>> available to in-tree tests that are going to stay that way? Or is this
>> just a matter of not having had time to "harden" or "certify" or
>> otherwise prepare those APIs for plugins to use them?
>
> "Staying that way" is certainly the impression given to users from
> other projects.
>
> In any case tempest is just an example. From my viewpoint, we need to
> make this a community default, to avoid even the short (which really
> ends up a long) term discrepancy between projects.
>
> If the standard in the community is equal access, this means when the
> next testing tool, CLI, SDK, $cross_project_tool comes along, it is
> available to all projects equally.
>
> If everyone uses the interfaces, they get better for all users of them,
> "big tent projects" and "tc-approved-release" alike. Having two
> way of doing the same thing means that there will always be
> discrepancies between people who are in the club, and those who are not.
>
> - Graham
>
>> Doug
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 

Re: [openstack-dev] [storlets] IRC meeting times

[eran]

Sure.
How about an hour later?
That is:
08:00 UTC
17:00 JST
11:00 IST

Also, are you ok with Tuesdays?

Quoting kajina...@nttdata.co.jp:


Hi Eran,


Thanks for your suggestion.

Is it possible to make the meeting time one hour earlier (08:00 UTC)  
or one hour later (09:00 UTC)?


Thank you,
Takashi

-Original Message-
From: e...@itsonlyme.name [mailto:e...@itsonlyme.name]
Sent: Wednesday, July 13, 2016 10:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [storlets] IRC meeting times

Hi,
I would like to change the IRC meeting times to Tuesdays at 07:00AM UTC
That's:
16:00 JST
10:00 IST

Any objections?
Thanks!
Eran



__
OpenStack Development Mailing 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] using feature branches, Swift's experiences

[John Dickinson]

Swift has now used 4 feature branches and landed 3 of them:

 * feature/sp -- for storage policy functionality (landed)
 * feature/ec -- for erasure codes (landed)
 * feature/hummingbird -- for golang WIP
 * feature/crypto -- for at-rest encryption (landed)

Overall, using long-lived upstream feature branches has been very helpful for 
us and overall a positive experience.

I've seen some other teams debate and discuss using a feature branch for their 
work but wonder about how it works. I've written down our experiences with 
using feature branches as part of OpenStack development, including some 
recommendations that help things go smoothly.

https://wiki.openstack.org/wiki/Swift/feature_branches

If you've got questions about using feature branches, please feel free to drop 
by #openstack-swift and ask.


--John





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

Re: [openstack-dev] 答复: [daisycloud-core] Nnominate Wei Kong as core for daisycloud-core project

[Jaivish Kothari]

+1

On Tue, Jul 19, 2016 at 9:29 AM,  wrote:

> +1
>
>
>
>
> 发件人: 胡智江180967/user/zte_ltd
> 收件人: openstack-dev@lists.openstack.org, huzhiji...@gmail.com,
> lu.yao...@zte.com.cn, zhou...@zte.com.cn, sun.jin...@zte.com.cn,
> kong.w...@zte.com.cn, janonymous.codevult...@gmail.com,
> WuWei10166727/user/zte_ltd@ZTE_LTD, HuZhiJiang180967/user/zte_ltd@ZTE_LTD,
>
> 日期: 2016/07/19 10:21
> 主题:[daisycloud-core] Nnominate Wei Kong as core for
> daisycloud-core project
> --
>
>
> Hi Team,
>
> I would like to propose adding Wei Kong(kong.w...@zte.com.cn) to the
> daisycloud-core core team. He has good experience on openstack
> development, previously he lead another team finished a BP of a
> cinder driver and his current commitment is on testing, ci for
> daisycloud-core. Until recently, He built flake8 test and deal most
> of the problems in the code, and he is working on build tempest for
> us now.
>
>
>
> 
> ZTE Information Security Notice: The information contained in this mail (and 
> any attachment transmitted herewith) is privileged and confidential and is 
> intended for the exclusive use of the addressee(s).  If you are not an 
> intended recipient, any disclosure, reproduction, distribution or other 
> dissemination or use of the information contained is strictly prohibited.  If 
> you have received this mail in error, please delete it and notify us 
> immediately.
>
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Mascot/logo for your project

[Thierry Carrez]

Julien Danjou wrote:

On Sat, Jul 16 2016, Thierry Carrez wrote:


Julien Danjou wrote:

Something is very unclear (but I'm getting used to it lol): are theses
logo created for projects or teams?

We have 4 different projects (Aodh, Gnocchi, Ceilometer & Panko) in the
Telemetry team. Should we have one or 4 mascots?


Heidi will likely confirm, but my understanding is that it's a mascot per team,
not per deliverable within that team. So in your case that would be the
"Telemetry" mascot.


Heidi, could you confirm that it is a mascot per team or per project?

Honestly, I don't think it'll suit us to have only one mascot/logo. It's
gonna be hard to use a logo marked "Telemetry" as a branding for our 4
different projects that do different things – even if it's in the same
area.


In my understanding, the mascot represents the team, not the project. So 
it represents the scope of the team and its members more than any 
particular by-product of that team.


For Telemetry, I'd choose a highly-distributed animal with multiple 
arms, like a starfish :)


But I'll let Heidi Joy confirm what the intent is here.

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tc][all] Plugins for all

[Hayes, Graham]

On 19/07/2016 16:39, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
>> On 18/07/2016 17:57, Thierry Carrez wrote:
>>> Hayes, Graham wrote:
 [...]
 The point is that we were supposed to be a level field as a community
 but if we have examples like this, there is not a level playing field.
>>>
>>> While I generally agree on your goals here (avoid special-casing some
>>> projects in generic support projects like Tempest), I want to clarify
>>> what we meant by "level playing field" in a recent resolution.
>>
>>
>> Yes - it has been pointed out the title is probably overloading a term
>> just used for a different purpose - I am more than willing to change it.
>>
>> I wasn't sure where I got the name, and I realised that was probably in
>> my head from that resolution.
>>
>>> This was meant as a level playing field for contributors within a
>>> project, not a level playing field between projects. The idea is that
>>> any contributor joining any OpenStack project should not be technically
>>> limited compared to other contributors on the same project. So, no
>>> "secret sauce" that only a subset of developers on a project have access to.
>>
>> There is a correlation here - "special sauce" (not secret obviously)
>> that only a subset of projects have access to.
>>
>>> I think I understand where you're gong when you say that all projects
>>> should have equal chances, but keep in mind that (1) projects should not
>>> really "compete" against each other (but rather all projects should
>>> contribute to the success of OpenStack as a whole) and (2) some
>>> OpenStack projects will always be more equal than others (for example we
>>> require that every project integrates with Keystone, and I don't see
>>> that changing).
>>
>> Yes, I agree we should not be competing. But was should not be asking
>> the smaller projects to re-implement functionality, just because they
>> did not get integrated in time.
>>
>> We require all projects to integrate with keystone for auth, as we
>> require all projects to integrate with neutron for network operations
>> and designate for DNS, I just see it as a requirement for using the
>> other components of OpenStack for their defined purpose.
>>
>
> It would be useful to have some specific information from the QA/Tempest
> team (and any others with a similar situation) about whether the current
> situation about how differences between in-tree tests and plugin tests
> are allowed to use various APIs. For example, are there APIs only
> available to in-tree tests that are going to stay that way? Or is this
> just a matter of not having had time to "harden" or "certify" or
> otherwise prepare those APIs for plugins to use them?

"Staying that way" is certainly the impression given to users from
other projects.

In any case tempest is just an example. From my viewpoint, we need to
make this a community default, to avoid even the short (which really
ends up a long) term discrepancy between projects.

If the standard in the community is equal access, this means when the
next testing tool, CLI, SDK, $cross_project_tool comes along, it is
available to all projects equally.

If everyone uses the interfaces, they get better for all users of them,
"big tent projects" and "tc-approved-release" alike. Having two
way of doing the same thing means that there will always be
discrepancies between people who are in the club, and those who are not.

- Graham

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


__
OpenStack Development Mailing List (not for 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][api] networking API reference clean up sprint

[Armando M.]

On 19 July 2016 at 06:49, Akihiro Motoki  wrote:

> Hi Neutron folks,
>
> As you may know, the OpenStack API references have been moved into
> individual project repositories.
> For the networking API, we have the api-ref document in neutron-lib
> repository.
> The api-ref document imported into neutron-lib repository needs to be
> cleaned up.
>
> I would like to plan a virtual sprint to clean up the networking API
> reference.
> I setup a etherpad for the sprint to share the guideline.
> (most are borrowed from nova api-ref sprint wiki)
>
> https://etherpad.openstack.org/p/neutron-api-ref-sprint
>
> I haven't set a specific period for the virtual sprint, but I would
> like to complete the sprint by Newton-3 milestone.
>

Akihiro,

Thanks for leading this effort.

With the Neutron mid-cycle approaching I think we should also take some
time to go over this aspect. I'll be sending out a draft of the mid-cycle
agenda later this week.

Cheers,
Armando


> Akihiro
>
> __
> OpenStack Development Mailing 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] [storlets] IRC meeting times

[kajinamit]

Hi Eran,


Thanks for your suggestion.

Is it possible to make the meeting time one hour earlier (08:00 UTC) or one 
hour later (09:00 UTC)?

Thank you,
Takashi

-Original Message-
From: e...@itsonlyme.name [mailto:e...@itsonlyme.name] 
Sent: Wednesday, July 13, 2016 10:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [storlets] IRC meeting times

Hi,
I would like to change the IRC meeting times to Tuesdays at 07:00AM UTC
That's:
16:00 JST
10:00 IST

Any objections?
Thanks!
Eran



__
OpenStack Development Mailing 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] [Magnum] What is Magnum's behaviour wrt Images in Glance and which ones are downloaded to COE ?

[Waines, Greg]

I have successfully setup devstack with Magnum,
following this link 
https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst#building-and-using-a-swarm-bay

I created a Docker-Swarm bay and successfully launched a simple container.

What is the behavior of MAGNUM wrt downloading of Container-formatted Images in 
Glance to the COE ?

e.g. in the setup from the above link
gwaines@wildcat-76:~$ glance -v image-list
+--+-+-+--+---++--+
| ID   | Name| 
Disk_format | Container_format | Size  | Status | Owner 
   |
+--+-+-+--+---++--+
| 96a63dda-e9e8-45ac-843c-1635909aa79e | cirros-0.3.4-x86_64-uec | ami  
   | ami  | 25165824  | active | 
a7e010ece2bf4bbfa84551a03c0770ae |
| 9ff4c5a2-30d8-4c46-ac3e-fde566654fec | cirros-0.3.4-x86_64-uec-kernel  | aki  
   | aki  | 4979632   | active | 
a7e010ece2bf4bbfa84551a03c0770ae |
| df11374e-ef88-47eb-8603-5e646fa7c76c | cirros-0.3.4-x86_64-uec-ramdisk | ari  
   | ari  | 3740163   | active | 
a7e010ece2bf4bbfa84551a03c0770ae |
| 296d607a-6d7a-472b-987d-8bcde63ff124 | fedora-atomic-latest| 
qcow2   | bare | 507928064 | active | 
a7e010ece2bf4bbfa84551a03c0770ae |
+--+-+-+--+---++--+
gwaines@wildcat-76:~$
gwaines@wildcat-76:~$ docker images
REPOSITORY  TAG IMAGE IDCREATED 
SIZE
swarm   1.0.0   4a0d7b83266a5 months ago
0 B
cirros  latest  807dd1cf91c76 months ago
0 B
gwaines@wildcat-76:~$

Does MAGNUM automatically download all Glance Images of a particular Container 
Format to the COE ?

In the above setup, which Glance Image does the ‘docker image’ “cirros” 
correspond to ?

Greg.









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

[openstack-dev] [Neutron][VPNaaS]IPSec Pluto is not running

[dongcan ye]

Hi, all

I want to install vpnaas in mitaka, but failed to create ipsec-connection.

OS version: Centos 7
Libreswan version: 3.10.0-327.18.2.el7.x86_64


In /etc/neutron/vpn_agent.ini, vpn_device_driver is
neutron_vpnaas.services.vpn.device_drivers.libreswan_ipsec.LibreSwanDriver.

Before running neutron-vpn-agent, I had checked ipsec status, it seems
normal:
# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Libreswan 3.15 (netkey) on 3.10.0-327.18.2.el7.x86_64
Checking for IPsec support in kernel [OK]
 SAref kernel support   [N/A]
 NETKEY:  Testing XFRM related proc values   [OK]
[OK]
[OK]
Hardware RNG detected, testing if used properly [OK]
Checking that pluto is running   [OK]
 Pluto listening for IKE on udp 500 [OK]
 Pluto listening for NAT-T on udp 4500   [OK]
Two or more interfaces found, checking IP forwarding [FAILED]
Checking NAT and MASQUERADEing   [OK]
Checking for 'ip' command   [OK]
Checking /bin/sh is not /bin/dash   [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]


After create ikepolicy, ipsecpolicy and vpn service, create a
ipsec-site-connection failed,
status code in vpn-agent.log returns 1 :
# ip netns exec qrouter-5758220e-5c35-429a-975f-39375db70efe ipsec whack
--ctlbase
/var/lib/neutron/ipsec/5758220e-5c35-429a-975f-39375db70efe/var/run/pluto
--status
whack: Pluto is not running (no
"/var/lib/neutron/ipsec/5758220e-5c35-429a-975f-39375db70efe/var/run/pluto.ctl")

By the way, ipsec checknss had already run, but I had not seen any db files
in the /etc/pki/nssdb directory:
root 14087  0.0  0.0 113252   912 ?S23:21   0:00 /bin/sh
/sbin/ipsec checknss
/var/lib/neutron/ipsec/5758220e-5c35-429a-975f-39375db70efe/etc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Mascot/logo for your project

[gordon chung]

On 19/07/16 03:50 AM, Julien Danjou wrote:

Heidi, could you confirm that it is a mascot per team or per project?

Honestly, I don't think it'll suit us to have only one mascot/logo. It's
gonna be hard to use a logo marked "Telemetry" as a branding for our 4
different projects that do different things – even if it's in the same
area.

hybrid animals. you can breed anything nowadays and build your own 
Franken-mascot. :P


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

[openstack-dev] [Manila] Logo Poll

[Ben Swartzlander]

https://www.surveymonkey.com/r/T9DW7G8

-Ben Swartzlander

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

[openstack-dev] [Glare][Heat][TripleO] Heat artifact type

[Oleksii Chuprykov]

Hello!

Today it was announced that Glare is ready for public review
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html So
we are ready to start working on integration Heat with Glare and
implementing a POC. After discussions with Glare team we see two design
options:

1) Create one artifact type that will contain template, nested templates
and environments.
Pros: It is easy to maintain integrity. Since artifact is immutable, we can
guarantee the consistency and prevent from accidentally removing of
dependent environment.
Cons: If we need to add new environments to use them with template, we need
to create new artifact.

2) Create 2 artifact types: environment and template.
Pros: It is easy to add new environments. You just need to create new
dependency from template artifact to environment one.
Cons: Some environment can be (mistakenly) removed, and template that have
dependencies on it will be in inconsistent state.

So we want to hear your opinions and suggestions on the matter. Thanks in
advance!

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

[openstack-dev] [puppet] Effort to standardize keystone middleware configurations

[Alex Schultz]

Hey All,

During our meeting today we discussed getting the keystone middleware
configuration for the services properly migrated to use the
keystone::resource::authtoken resource. I've created a bug[0] to track the
effort.  If you wish to assist with this effort, please update the bug with
your name and which module you are working on.

[0] https://bugs.launchpad.net/puppet-aodh/+bug/1604463

Thanks,
-Alex
__
OpenStack Development Mailing List (not for 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][all] Plugins for all

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
> On 18/07/2016 17:57, Thierry Carrez wrote:
> > Hayes, Graham wrote:
> >> [...]
> >> The point is that we were supposed to be a level field as a community
> >> but if we have examples like this, there is not a level playing field.
> >
> > While I generally agree on your goals here (avoid special-casing some
> > projects in generic support projects like Tempest), I want to clarify
> > what we meant by "level playing field" in a recent resolution.
> 
> 
> Yes - it has been pointed out the title is probably overloading a term
> just used for a different purpose - I am more than willing to change it.
> 
> I wasn't sure where I got the name, and I realised that was probably in
> my head from that resolution.
> 
> > This was meant as a level playing field for contributors within a
> > project, not a level playing field between projects. The idea is that
> > any contributor joining any OpenStack project should not be technically
> > limited compared to other contributors on the same project. So, no
> > "secret sauce" that only a subset of developers on a project have access to.
> 
> There is a correlation here - "special sauce" (not secret obviously)
> that only a subset of projects have access to.
> 
> > I think I understand where you're gong when you say that all projects
> > should have equal chances, but keep in mind that (1) projects should not
> > really "compete" against each other (but rather all projects should
> > contribute to the success of OpenStack as a whole) and (2) some
> > OpenStack projects will always be more equal than others (for example we
> > require that every project integrates with Keystone, and I don't see
> > that changing).
> 
> Yes, I agree we should not be competing. But was should not be asking
> the smaller projects to re-implement functionality, just because they
> did not get integrated in time.
> 
> We require all projects to integrate with keystone for auth, as we
> require all projects to integrate with neutron for network operations
> and designate for DNS, I just see it as a requirement for using the
> other components of OpenStack for their defined purpose.
> 

It would be useful to have some specific information from the QA/Tempest
team (and any others with a similar situation) about whether the current
situation about how differences between in-tree tests and plugin tests
are allowed to use various APIs. For example, are there APIs only
available to in-tree tests that are going to stay that way? Or is this
just a matter of not having had time to "harden" or "certify" or
otherwise prepare those APIs for plugins to use them?

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

[openstack-dev] [TripleO] CI Driven Documentation: Design Discussion

[Harry Rybacki]

All,

During today's rdo-ci scrum[1], I briefed the team on PoC work that
will bring trown's old PoC[2] review inline with the current state of
affairs of TripleO-Quickstart (OOOQS) and related ansible roles used
heavily in upstream CI[3].

To summarize, our goal is to leverage the power Sphinx[4] and
templated bash scripts[5] generated during jobs to decrease the
overhead of maintaining TripleO docs. Additionally, we aim to provide
more build specific e.g., this is how you would do a minimal
deployment on [centos|rhelx|...], documentation with as much
automation as possible.

In trown's initial PoC[2] conditionals are used to inside of the
templates to allow for selective addition of RST blocks and removal of
non-useful chunks of code (CI specific) for documentation[6]. The
resulting docs are quite aesthetically pleasing[7]. The multitude of
roles which are
now consumed for any given build and used by OOOQS complicates things a
bit.

Regardless of how we move forward, roles, such as
tripleo-undercloud-post[8], will have to update their relevant bash
templates[9].

Two ideas were discussed:

1. Minimally modify the templates to have inline comments which would
equate to "steps" which can then be followed to reproduce a build.
  - This would require the least work bringing roles up to speed but
would in turn lose the ability to use much of RST's power.
  - This would make automated documentation incredibly easy -- just
pull relevant bash scripts off of the LastSuccessfullBuild from the
artifacts server for a given job every XX hours and

2. Modify the templates to conditionally add snippets as noted in the
original PoC[6].
  - This would provide the ability to have highly customizable
documentation and all of the givens from using RST
  - This would require executing roles twice (once for the build and
once for producing the documentation version of the scripts used
during the build).
- Other problem areas could result from this. For example, vars
set dynamically during a roles execution during the initial build
might not be available (or different) during the second execution.

While I think that we should strive to have the flexibility RST
provides us, the MVP (option 1) already gives us (and our users) a
huge leg up already with continually up-to-date documentation that has
been tested (and built by) our CI.

Any thoughts on the above would be greatly appreciated  -- perhaps
there is a clean way to generate two sets of templated bash in tandem
and we can just pull the documentation version off of the artifacts
server?

[1] - http://rdo-ci-cd.etherpad.corp.redhat.com/weekly-scrum
[2] - https://review.gerrithub.io/#/c/261218/
[3] - https://github.com/HarryRybacki/tripleo-documentor
[4] - http://www.sphinx-doc.org/en/stable/
[5] - 
https://github.com/openstack/tripleo-quickstart/tree/master/roles/tripleo/undercloud/templates
[6] - 
https://review.gerrithub.io/#/c/261218/1/playbooks/roles/images/undercloud/templates/undercloud-run
[7] - https://trown.fedorapeople.org/rdodocgen/
[8] - https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post
[9] - 
https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post/blob/master/templates/undercloud-install-post.sh.j2

Thanks, all!


/R

Harry Rybacki
Software Engineer, Red Hat

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

Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

[Mauricio Lima]

+1

2016-07-19 12:23 GMT-03:00 Vikram Hosakote (vhosakot) :

> +1 sure.
>
> Regards,
> Vikram Hosakote
> IRC:  vhosakot
>
> From: Michał Jastrzębski 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, July 19, 2016 at 9:20 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag
>
> +1 ofc
>
> On 19 July 2016 at 06:02, Ryan Hallisey  wrote:
>
> +1
>
> -Ryan
>
> - Original Message -
> From: "Jeffrey Zhang" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Sent: Monday, July 18, 2016 9:16:09 PM
> Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag
>
> +1 to apply
> I'd like to be the volunteer.
>
> On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
>  wrote:
>
> On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke 
> wrote:
>
> Hi Steve,
>
> +1 to applying. I'll volunteer for the backport team also.
>
> -Paul
>
>
> On 18/07/16 13:07, Steven Dake (stdake) wrote:
>
>
> Hey Koalians,
>
> I'd like us to consider applying  for the stable follows policy tag.
>Full details are here:
>
>
>
> http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst
>
> Because of the magic work we did to make liberty functional, it is
> possible that we may not be able to apply for this tag until Liberty
> falls into EOL.  Still I personally believe intent matters most, and our
> intent has always been for these to be stable low-rate-of-change
> no-feature-backport branches.  There are some exceptions I think we
> would fit under for the Liberty case, so I think it is worth a shot.
>
> I'd need 2-4 people to commit to joining the stable backport team for
> Kolla reviews specifically.  These folks would be the only folks that
> could ACK patches in the stable branch maintenance queue.  Anyone could
> continue to submit backport patches as they desire.
>
> I'll leave voting open for 1 week or until there I a majority (6 core
> reviewers) or until there is a unanimous vote.  If there is not, then we
> won't apply.  The deadline for this vote is July 25th.
>
> Thanks!
> -steve
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> +1 to apply for stable follows policy.
> I would like to volunteer for the backport team.
>
> __
> OpenStack Development Mailing 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,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] [kolla][vote] Applying for stable-follows tag

[Vikram Hosakote (vhosakot)]

+1 sure.

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, July 19, 2016 at 9:20 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 ofc

On 19 July 2016 at 06:02, Ryan Hallisey 
> wrote:
+1

-Ryan

- Original Message -
From: "Jeffrey Zhang" >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Sent: Monday, July 18, 2016 9:16:09 PM
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 to apply
I'd like to be the volunteer.

On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
> wrote:
On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke 
> wrote:
Hi Steve,

+1 to applying. I'll volunteer for the backport team also.

-Paul


On 18/07/16 13:07, Steven Dake (stdake) wrote:

Hey Koalians,

I'd like us to consider applying  for the stable follows policy tag.
   Full details are here:


http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

Because of the magic work we did to make liberty functional, it is
possible that we may not be able to apply for this tag until Liberty
falls into EOL.  Still I personally believe intent matters most, and our
intent has always been for these to be stable low-rate-of-change
no-feature-backport branches.  There are some exceptions I think we
would fit under for the Liberty case, so I think it is worth a shot.

I'd need 2-4 people to commit to joining the stable backport team for
Kolla reviews specifically.  These folks would be the only folks that
could ACK patches in the stable branch maintenance queue.  Anyone could
continue to submit backport patches as they desire.

I'll leave voting open for 1 week or until there I a majority (6 core
reviewers) or until there is a unanimous vote.  If there is not, then we
won't apply.  The deadline for this vote is July 25th.

Thanks!
-steve




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


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

+1 to apply for stable follows policy.
I would like to volunteer for the backport team.

__
OpenStack Development Mailing 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,
Jeffrey Zhang
Blog: http://xcodest.me

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

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

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

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

Re: [openstack-dev] [TripleO] Integration of non-puppet service configuration?

[Emilien Macchi]

On Tue, Jul 19, 2016 at 11:12 AM, Steven Hardy  wrote:
> Hi all,
>
> Recently I've had a few discussions around $subject, and in particular
> there are folks involved in our community who would like to enable an
> optional alternative so puppet-ceph for configuring ceph services in a
> deployed overcloud.
>
> The alternative under discussion is ceph-ansible, and I did a minimal PoC
> that shows the roles provided there can be driven via a similar method to
> our existing puppet deployments:
>
> https://github.com/hardys/heat-ceph-templates/blob/master/mon_cluster.yaml#L61
>
> Instead of hieradata we'll have to wire the parameter derived values in to
> each deployment (there may be other possible approaches, but this is how
> the heat hook works by default).
>
> It gets a bit (well, a lot actually) more complex when you consider how we
> wire this in to tripleo-heat-templates, because atm we assume we can
> combine all of the role_data config_settings and step_config data.
>
> I don't think this works as well with ansible (because it's a more
> imperative tool, and doesn't build a global catalog like puppet does), and
> we also don't have any way to enable a mixture of puppet and ansible
> deployed services right now.
>
> All of this is definitely long-term (e.g Ocata and beyond), but I'd like to
> get feedback of how we might make this possible, and if the service
> abtractions we have in place now are sufficient to enable choice in config
> management tooling long term.
>
> Note that we'd probably still enable puppet-ceph by default, but this would
> be an alternative which could be supported in paralell.
>
> One thing which occurs to me is there's risk of config-management
> split-brain, so we probably want to make this work depend on container
> based deployments - any thoughts on e.g enabling external config generation
> via ansible vis the puppet approach we have already proven?

One thing about it, and you highlighted it very well:
we need to make sure ceph-ansible does not manage a resource that our
puppet deployment already do.

Example:
puppet create file1 but ansible removes file1.

If we disable puppet-ceph usage in TripleO, we also need to make sure
ceph-ansible is not intrusive as touching other resources that we
already manage in TripleO.
Other than that, I think it's doable.


Secondo, I would like to investigate when running Puppet and Ansible
in term of steps. For example, in the case of hyperconverged setup, we
need to make Ceph working before Cinder service to start for example.
Anyway, I think in the case of Ceph it's pretty safe to first deploy
Ceph before OpenStack. But what about future things we will integrate?
How to mix them within our steps? Just adding an area to investigate.

> Feel free to jump in with your thoughts here, and perhaps we can arrange
> some live discussion with those folks interested in due course too.
>
> Thanks,
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

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

Re: [openstack-dev] [TripleO] tripleo-common bugs, bug tracking and launchpad tags

[Steven Hardy]

On Mon, Jul 18, 2016 at 12:28:10PM +0100, Julie Pichon wrote:
> Hi,
> 
> On Friday Dougal mentioned on IRC that he hadn't realised there was a
> separate project for tripleo-common bugs on Launchpad [1] and that he'd
> been using the TripleO main tracker [2] instead.
> 
> Since the TripleO tracker is also used for client bugs (as far as I can
> tell?), and there doesn't seem to be a huge amount of tripleo-common
> bugs perhaps it would make sense to also track those in the main
> tracker? If there is a previous conversation or document about bug
> triaging beyond [3] I apologise for missing it (and would love a
> URL!). At the moment it's a bit confusing.

Thanks for raising this, yes there is a bit of a proliferation of LP
projects, but FWIW the only one I'm using to track coordinated milestone
releases for Newton is this one:

https://launchpad.net/tripleo/

> If we do encourage using the same bug tracker for multiple components,
> I think it would be useful to curate a list of official tags [4]. The
> main advantage of doing that is that the tags will auto-complete so
> it'd be easier to keep them consistent (and thus actually useful).

+1 I'm fine with adding tags, but I would prefer that we stopped adding
more LP projects unless the associated repos aren't planned to be part of
the coordinated release (e.g I don't have to track them ;)

> Personally, I wanted to look through open bugs against
> python-tripleoclient but people use different ways of marking them at
> the moment - e.g. [tripleoclient] or [python-tripleoclient] or
> tripleoclient (or nothing?) in the bug name. I tried my luck at adding
> a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe
> something shorter like 'cli', 'common' would make more sense. If there
> are other tags that come back regularly it'd probably be helpful to
> list them explicitly as well.

Sure, well I know that many python-*clients do have separate LP projects,
but in the case of TripleO our client is quite highly coupled to the the
other TripleO pieces, in particular tripleo-common.  So my vote is to
create some tags in the main tripleo project and use that to filter bugs as
needed.

There are two projects we might consider removing, tripleo-common, which
looks pretty much unused and tripleo-validations which was recently added
by the sub-team working on validations.

If folks find either useful then they can stay, but it's going to be easier
to get a clear view on when to cut a release if we track everything
considered part of the tripleo deliverable in one place IMHO.

Thanks,

Steve

> 
> Julie
> 
> [1] https://bugs.launchpad.net/tripleo-common
> [2] https://bugs.launchpad.net/tripleo
> [3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage
> [4] https://wiki.openstack.org/wiki/Bug_Tags
> [5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Steve Hardy
Red Hat Engineering, Cloud

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

Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

[Hayes, Graham]

On 19/07/2016 15:11, Joshua Harlow wrote:
> Hayes, Graham wrote:
>> On 18/07/16 22:27, Ronald Bradford wrote:
>>> Hi All,
>>>
>>> For Oslo libraries we ensure that API's are backward compatible for 1+ 
>>> releases.
>>> When an Oslo API adds a new class attribute (as in this example of
>>> is_admin_project and 4 other attributes) added to Oslo Context in
>>> 2.6.0,  these are added to ensure this API is also forward compatible
>>> with existing project code for any contract with the base class
>>> instantiation or manipulation.
>>
>> Which projects is this run against?
>>
>>> The issue seen is presently Nova specific (as other projects can
>>> utilize 2.6.0) and it is related to projects that sub-class
>>> oslo.context, and how unit tests are written for using class
>>> parameters.  Ideally, to implement using oslo.context correctly
>>> OpenStack projects should:
>>
>> Designate also had to make a quick change to support 2.6.0.
>>
>> We were lucky as it was noticed by the RDO builds, which had pulled in
>> 2.6.0 before the requirements update was proposed, so it did not break
>> our gate.
>>
>> I just did a quick search and there is a few projects that hardcoded
>> this, like we did.
>
> Ya, that's bad, nothing in the docs of the to_dict API say what to even
> compare against (or the keys produced), so I'm pretty sure anyone doing
> this is setting themselves up for future failure and fragile software.
>
>>
>>> * Not perform direct dictionary to dictionary comparisons with the
>>> to_dict() method as this does not support when new attributes at
>>> added. Two patches (one to nova) address this in offending projects
>>> [5][6]
>>> * Unit tests should focus on attributes specific to the sub-classed
>>> signature, e.g. [7].  Oslo context provides an extensive set of unit
>>> tests for base class functionality. This is a wish list item for
>>> projects to implement.
>>>
>>> The to_dict() method exists as a convenience method only and is not an
>>> API contract. The resulting set of keys should be used accordingly.
>>> This is why there is no major release version.
>>
>> How are developers supposed to know that?
>
> So we (in oslo) can (and ideally will) make this better but when the API
> doesn't itself tell you what keys are produced or what the values of
> those keys are then it should be pretty obvious to u (the library user)
> that u can not reliably do dictionary comparisons (because how do u know
> what to compare against when the docs don't state that?). I suppose
> people are 'reverse engineering the dict' by just looking at the code
> but that's also not so great...

Its worth noting we took what we had from the context in olso incubator
and moved to oslo.context in 2014. (at that point is was a straight
swap of the import, and a single rename.)

We haven't had to change it since then - so I would have considered it
a stable interface.

>>
>> This kind of feels like semantics. This was an external API that changed
>> and as a result should have been a major version.
>
> I think this is where it gets a little bit into as u said, semantics,
> but the semantics IMHO are important here because it affects the ability
> of oslo.context to move forward & change.
>
> I suppose we should/could just put a warning on this method like I did
> in taskflow (for something similar) @
> https://github.com/openstack/taskflow/blob/master/taskflow/engines/base.py#L71
> to denote that nothing in the dict that is returned can be guaranteed to
> always be the same.

Or even in the usage section of the docs, show how you should use it
properly, and explain that the keys can (and will over time) change.

>>
>>> There is a note from our discussion in Oslo to improve our
>>> documentation to describe the API use of to_dict() better and state we
>>> will not remove to_dict() keys within a release, but that may happen
>>> between releases.
>>>
>>> There is a subsequent problem with how Nova performs a warning test
>>> [8]. Additional reviews are looking at addressing this sub-class usage
>>> of from_dict() and to_dict().
>>>
>>> Regards
>>>
>>> Ronald
>>>
>>>
>>> [5] https://review.openstack.org/#/c/343694/,
>>> [6] https://review.openstack.org/#/c/342367/
>>> [7] https://review.openstack.org/#/c/342869/
>>> [8] 
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144
>>>
>>> On Mon, Jul 18, 2016 at 10:50 AM, Matt Riedemann
>>>   wrote:
 On 7/18/2016 9:42 AM, Matt Riedemann wrote:
> On 7/18/2016 9:09 AM, Markus Zoeller wrote:
>> Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
>> change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
>> Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
>> Portland and won't be available for the next 2h or so.
>> If you can have a look at it and merge it, that would be great.
>>
>> References:
>> [1]
>>
>> 

Re: [openstack-dev] [TripleO] Proposing Gabriele Cerami for tripleo-quickstart core

[Steven Hardy]

On Mon, Jul 18, 2016 at 11:06:53AM -0400, John Trowbridge wrote:
> Howdy,
> 
> I would like to propose Gabriele (panda on IRC), for tripleo-quickstart
> core. He has worked on some pretty major features for the project
> (explicit teardown, devmode), and has a good understanding of the code base.
> 
> This will bring us to three dedicated core reviewers for
> tripleo-quickstart (myself and larsks being the other two), so I would
> also like to implement a 2x +2 policy at this time. Note, that all cores
> of TripleO are also cores on tripleo-quickstart, and should feel free to
> +2 changes as they are comfortable.
> 
> If there are no objections, I will put in a change at the end of the week.

I've not been much involved with tripleo-quickstart reviews myself, but +1
from me :)

Steve

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

[openstack-dev] [TripleO] Integration of non-puppet service configuration?

[Steven Hardy]

Hi all,

Recently I've had a few discussions around $subject, and in particular
there are folks involved in our community who would like to enable an
optional alternative so puppet-ceph for configuring ceph services in a
deployed overcloud.

The alternative under discussion is ceph-ansible, and I did a minimal PoC
that shows the roles provided there can be driven via a similar method to
our existing puppet deployments:

https://github.com/hardys/heat-ceph-templates/blob/master/mon_cluster.yaml#L61

Instead of hieradata we'll have to wire the parameter derived values in to
each deployment (there may be other possible approaches, but this is how
the heat hook works by default).

It gets a bit (well, a lot actually) more complex when you consider how we
wire this in to tripleo-heat-templates, because atm we assume we can
combine all of the role_data config_settings and step_config data.

I don't think this works as well with ansible (because it's a more
imperative tool, and doesn't build a global catalog like puppet does), and
we also don't have any way to enable a mixture of puppet and ansible
deployed services right now.

All of this is definitely long-term (e.g Ocata and beyond), but I'd like to
get feedback of how we might make this possible, and if the service
abtractions we have in place now are sufficient to enable choice in config
management tooling long term.

Note that we'd probably still enable puppet-ceph by default, but this would
be an alternative which could be supported in paralell.

One thing which occurs to me is there's risk of config-management
split-brain, so we probably want to make this work depend on container
based deployments - any thoughts on e.g enabling external config generation
via ansible vis the puppet approach we have already proven?

Feel free to jump in with your thoughts here, and perhaps we can arrange
some live discussion with those folks interested in due course too.

Thanks,

Steve

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

Re: [openstack-dev] [heat][yaql] Heat map replacement options

[Steven Hardy]

On Fri, Jul 15, 2016 at 10:25:39AM +0100, Steven Hardy wrote:
> Hi all,
> 
> I'm trying to figure out the cleanest way to do a replacement of values in
> a mapping (json parameter) in a heat template, e.g:
> 
>   ServiceNetMap:
> type: json
> default:
>   IronicApiNetwork: internal_api
>   CephPublicNetwork: storage
> 
>   NetIpMap:
> type: json
> default:
>   storage: 192.0.2.2
>   internal_api: 192.0.2.5
> 
> How do I get
>   OutputMap:
> IronicApiNetwork: 192.0.2.5
> CephPublicNetwork: 192.0.2.2
> 
> It seems like something yaql should be able to do, but I've so far failed
> to figure out the syntax.
> 
> The other (possibly simpler) possibility is to implement a new hot
> function, e.g something like:
> 
>   map_replace:
> template: {get_param: ServiceNetMap}
> value_replacements: {get_param: NetIpMap}

As a follow-up to this, I have posted this spec and implementation for
map_replace (syntax differs slightly from the keys above):

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

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

My aim is a simpler interface to the yaql example previously discussed, and
a better error path when things like key collisions occur. Reviews welcome! :)

Steve

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

[openstack-dev] [Infra][Fuel-ccp] Third party CI

[Artur Zarzycki]

Hi all,
I would like to propose Mirantis Fuel CCP CI [1] for voting permissions 
in fuel-ccp* projects.

It runs last time as non-voting CI and it looks stable now.
We prepared in ci-sandbox repository some CRs[2] to show that 
build/votes are repeatable

and logs are accessible[3]


[1] https://wiki.openstack.org/wiki/ThirdPartySystems/Fuel_CCP_CI
[2] https://review.openstack.org/#/c/340285/ (success) 
https://review.openstack.org/#/c/340280/ (fail)

[3] http://logs.mcp.fuel-infra.org/jenkins-tp/verify-tox-py27/builds/58/log

Best Regards
Artur Zarzycki

__
OpenStack Development Mailing 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] [oslo.db] [CC neutron] CIDR overlap functionality and constraints

[Mike Bayer]

Oslo.db devs :

We've developed a system by which CIDR math, such as that of detecting 
region overlaps, can be performed on a MySQL database within queries [1] 
[2].   This feature makes use of a custom stored function I helped to 
produce which provides functionality similar to that which Postgresql 
provides built in [3].   SQLite also supports a simple way to add CIDR 
math functions as well which I've demonstrated at [4].


Note that I use the term "function" and not "procedure" to stress that 
this is not a "stored procedure" in the traditional sense of performing 
complex business logic and persistence operations - this CIDR function 
performs a calculation that is not at all specific to Openstack, and is 
provided already by other databases as a built-in, and nothing else.


The rationale for network-math logic being performed in the relational 
database is so that SQL like SELECT, UPDATE, and INSERT can make use of 
CIDR overlaps and other network math, such as to locate records that 
correspond to network ranges in some way and of course to provide guards 
and constraints, like that of concurrent UPDATE statements against 
conflicting ranges as well as being able to produce INSERT constraints 
for similar reasons.   Both MySQL and Postgresql have support for 
network number functions, Postgresql just has a lot more.


The INSERT constraint problem is also addressed by our patch and makes 
use of an INSERT trigger on MySQL [5], but on Postgresql we use a GIST 
index which has been shown to be more reliable under concurrent use than 
a trigger on this backend [6].


Not surprisingly, there's a lot of verbosity to both the production of 
the MySQL CIDR overlap function and the corresponding trigger and 
constraint, as well as the fact that to support the addition of these 
functions / constraints at both the Alembic migration level as well as 
that of the model level (because we would like metadata.create_all() to 
work), they are currently stated twice within this patch within their 
full verbosity.This is sub-optimal, and while the patch here makes 
use of an Alembic recipe [7] to aid in the maintenance of special DDL 
constructs, it's adding lots of burden to the Neutron codebase that 
could be better stated elsewhere.


The general verbosity and unfamiliarity of these well known SQL features 
is understandably being met with trepidation.  I've identified that this 
trepidation is likely rooted in the fact that unlike the many other 
elaborate SQL features we use like ALTER TABLE, savepoints, subqueries, 
SELECT FOR UPDATE, isolation levels, etc. etc., there is no warm and 
fuzzy abstraction layer here that is both greatly reducing the amount of 
explicit code needed to produce and upgrade the feature, as well as 
indicating that "someone else" will fix this system when it has problems.


Rather than hobbling the entire Openstack ecosystem to using a small 
subset of what our relational databases are capable of, I'd like to 
propose that preferably somewhere in oslo.db, or elsewhere, we begin 
providing the foundation for the use of SQL features that are rooted in 
mechanisms such as triggers and small use of stored functions, and more 
specifically begin to produce network-math SQL features as the public 
API, starting with this one.



[1] 
https://review.openstack.org/gitweb?p=openstack/neutron.git;a=blob;f=neutron/db/migration/alembic_migrations/versions/newton/expand/5bbf1e0b1774_add_stored_procedure_and_trigger_for_.py;h=8af394d319d119f57b224d391c844c0a87178856;hb=90f46e235672d3917015e5c49aa0513fb1de7ba9#l36


[2] https://review.openstack.org/#/c/314054/

[3] https://www.postgresql.org/docs/9.1/static/functions-net.html

[4] https://gist.github.com/zzzeek/a3bccad40610b9b69803531cc71a79b1

[5] 
https://review.openstack.org/gitweb?p=openstack/neutron.git;a=blob;f=neutron/db/migration/alembic_migrations/versions/newton/expand/5bbf1e0b1774_add_stored_procedure_and_trigger_for_.py;h=8af394d319d119f57b224d391c844c0a87178856;hb=90f46e235672d3917015e5c49aa0513fb1de7ba9#l92


[6] 
https://review.openstack.org/gitweb?p=openstack/neutron.git;a=blob;f=neutron/db/migration/alembic_migrations/versions/newton/expand/5bbf1e0b1774_add_stored_procedure_and_trigger_for_.py;h=8af394d319d119f57b224d391c844c0a87178856;hb=90f46e235672d3917015e5c49aa0513fb1de7ba9#l116


[7] 
http://alembic.zzzcomputing.com/en/latest/cookbook.html#replaceable-objects


__
OpenStack Development Mailing List (not for 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][all] Big tent? (Related to Plugins for all)

[Joshua Harlow]

Julien Danjou wrote:

On Mon, Jul 18 2016, Joshua Harlow wrote:


Thus why I think the starting of the architecture working group is a good
thing; because I have a believe that people are forgetting among all of this
that such a group holds a lot of the keys to the kingdom (whether u, the
reader, want to admit that or not is well the readers problem) in openstack
(sorry and no disrespect to independent folks&  contributors), but most of us
work for large companies that have architects (and leads) and if those
architects (and leads) can get together cross-company to aggregate and (agree
on) and solve actual problems then that really is IMHO the only way to keep our
projects healthy (assuming we can even do that at this stage).


I think it is a bit naive to think any working group is going to fix
architectural problems. You know first hand what happened¹ with the Nova
service group and tooz for example.

¹  Nothing.



Totally fair, but I still 'somewhat believe' that something good may 
come out of this. No I don't have a lot (I can probably count them on 
one hand) success stories with regards to this kind of cross-project 
work but it's not so easy to pin-point why things happened this way 
(without getting into speculation/theorizing territory).


__
OpenStack Development Mailing List (not for 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] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

[Joshua Harlow]

Hayes, Graham wrote:

On 18/07/16 22:27, Ronald Bradford wrote:

Hi All,

For Oslo libraries we ensure that API's are backward compatible for 1+ releases.
When an Oslo API adds a new class attribute (as in this example of
is_admin_project and 4 other attributes) added to Oslo Context in
2.6.0,  these are added to ensure this API is also forward compatible
with existing project code for any contract with the base class
instantiation or manipulation.


Which projects is this run against?


The issue seen is presently Nova specific (as other projects can
utilize 2.6.0) and it is related to projects that sub-class
oslo.context, and how unit tests are written for using class
parameters.  Ideally, to implement using oslo.context correctly
OpenStack projects should:


Designate also had to make a quick change to support 2.6.0.

We were lucky as it was noticed by the RDO builds, which had pulled in
2.6.0 before the requirements update was proposed, so it did not break
our gate.

I just did a quick search and there is a few projects that hardcoded
this, like we did.


Ya, that's bad, nothing in the docs of the to_dict API say what to even 
compare against (or the keys produced), so I'm pretty sure anyone doing 
this is setting themselves up for future failure and fragile software.





* Not perform direct dictionary to dictionary comparisons with the
to_dict() method as this does not support when new attributes at
added. Two patches (one to nova) address this in offending projects
[5][6]
* Unit tests should focus on attributes specific to the sub-classed
signature, e.g. [7].  Oslo context provides an extensive set of unit
tests for base class functionality. This is a wish list item for
projects to implement.

The to_dict() method exists as a convenience method only and is not an
API contract. The resulting set of keys should be used accordingly.
This is why there is no major release version.


How are developers supposed to know that?


So we (in oslo) can (and ideally will) make this better but when the API 
doesn't itself tell you what keys are produced or what the values of 
those keys are then it should be pretty obvious to u (the library user) 
that u can not reliably do dictionary comparisons (because how do u know 
what to compare against when the docs don't state that?). I suppose 
people are 'reverse engineering the dict' by just looking at the code 
but that's also not so great...




This kind of feels like semantics. This was an external API that changed
and as a result should have been a major version.


I think this is where it gets a little bit into as u said, semantics, 
but the semantics IMHO are important here because it affects the ability 
of oslo.context to move forward & change.


I suppose we should/could just put a warning on this method like I did 
in taskflow (for something similar) @ 
https://github.com/openstack/taskflow/blob/master/taskflow/engines/base.py#L71 
to denote that nothing in the dict that is returned can be guaranteed to 
always be the same.





There is a note from our discussion in Oslo to improve our
documentation to describe the API use of to_dict() better and state we
will not remove to_dict() keys within a release, but that may happen
between releases.

There is a subsequent problem with how Nova performs a warning test
[8]. Additional reviews are looking at addressing this sub-class usage
of from_dict() and to_dict().

Regards

Ronald


[5] https://review.openstack.org/#/c/343694/,
[6] https://review.openstack.org/#/c/342367/
[7] https://review.openstack.org/#/c/342869/
[8] 
http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144

On Mon, Jul 18, 2016 at 10:50 AM, Matt Riedemann
  wrote:

On 7/18/2016 9:42 AM, Matt Riedemann wrote:

On 7/18/2016 9:09 AM, Markus Zoeller wrote:

Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
Portland and won't be available for the next 2h or so.
If you can have a look at it and merge it, that would be great.

References:
[1]

https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1

[2] https://review.openstack.org/#/c/342604/1
[3] https://bugs.launchpad.net/nova/+bug/1603979
[4] logstash: http://goo.gl/79yFb9


This is an API change for oslo.context, why wasn't it released as 3.0.0?

Seems we should revert the upper-constraints bump and blacklist 2.6.0,
then get that released as 3.0.0.


Here is the blacklist:

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


--

Thanks,

Matt Riedemann


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

[openstack-dev] [neutron][api] networking API reference clean up sprint

[Akihiro Motoki]

Hi Neutron folks,

As you may know, the OpenStack API references have been moved into
individual project repositories.
For the networking API, we have the api-ref document in neutron-lib repository.
The api-ref document imported into neutron-lib repository needs to be
cleaned up.

I would like to plan a virtual sprint to clean up the networking API reference.
I setup a etherpad for the sprint to share the guideline.
(most are borrowed from nova api-ref sprint wiki)

https://etherpad.openstack.org/p/neutron-api-ref-sprint

I haven't set a specific period for the virtual sprint, but I would
like to complete the sprint by Newton-3 milestone.

Akihiro

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

Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

[Michał Jastrzębski]

+1 ofc

On 19 July 2016 at 06:02, Ryan Hallisey  wrote:
> +1
>
> -Ryan
>
> - Original Message -
> From: "Jeffrey Zhang" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Monday, July 18, 2016 9:16:09 PM
> Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag
>
> +1 to apply
> I'd like to be the volunteer.
>
> On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
>  wrote:
>> On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke  wrote:
>>> Hi Steve,
>>>
>>> +1 to applying. I'll volunteer for the backport team also.
>>>
>>> -Paul
>>>
>>>
>>> On 18/07/16 13:07, Steven Dake (stdake) wrote:

 Hey Koalians,

 I'd like us to consider applying  for the stable follows policy tag.
   Full details are here:


 http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst

 Because of the magic work we did to make liberty functional, it is
 possible that we may not be able to apply for this tag until Liberty
 falls into EOL.  Still I personally believe intent matters most, and our
 intent has always been for these to be stable low-rate-of-change
 no-feature-backport branches.  There are some exceptions I think we
 would fit under for the Liberty case, so I think it is worth a shot.

 I'd need 2-4 people to commit to joining the stable backport team for
 Kolla reviews specifically.  These folks would be the only folks that
 could ACK patches in the stable branch maintenance queue.  Anyone could
 continue to submit backport patches as they desire.

 I'll leave voting open for 1 week or until there I a majority (6 core
 reviewers) or until there is a unanimous vote.  If there is not, then we
 won't apply.  The deadline for this vote is July 25th.

 Thanks!
 -steve




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

>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> +1 to apply for stable follows policy.
>> I would like to volunteer for the backport team.
>>
>> __
>> OpenStack Development Mailing 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,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] [new][openstack] osc-lib 0.4.0 release (newton)

[no-reply]

We are eager to announce the release of:

osc-lib 0.4.0: OpenStackClient Library

This release is part of the newton release series.

With source available at:

https://git.openstack.org/cgit/openstack/osc-lib

With package available at:

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

Please report issues through launchpad:

https://bugs.launchpad.net/python-openstackclient

For more details, please see below.

Changes in osc-lib 0.3.0..0.4.0
---

2202617 Add Python 3.5 classifier and venv
fab2362 Updated from global requirements
b1022ac Fix v2 auth with v3 args present
cfcb8b0 trivial whitespace change to kick off docs publishing
13850bc Remove discover from test-requirements
ece28e8 Remove discover from test-reqs
f56575f Remove setting project name on clientmanager


Diffstat (except docs and test files)
-

README.rst  |  2 +-
osc_lib/cli/client_config.py| 28 +-
osc_lib/clientmanager.py|  6 ---
requirements.txt|  2 +-
setup.cfg   |  1 +
test-requirements.txt   |  1 -
7 files changed, 80 insertions(+), 53 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index dd1641f..b3760b4 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -14 +14 @@ simplejson>=2.2.0 # MIT
-stevedore>=1.10.0 # Apache-2.0
+stevedore>=1.16.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index d000a8a..f9215a2 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -7 +6,0 @@ coverage>=3.6 # Apache-2.0
-discover # BSD



__
OpenStack Development Mailing List (not for 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-operators] [puppet] [keystone] support for mysql_sql_mode

[Emilien Macchi]

On Tue, Jul 19, 2016 at 4:57 AM, Constantinescu David Alexandru
 wrote:
> Hi Guys
>
> Do you think it's possible to add support for setting mysql_sql_mode in the
> keystone puppet module?
>
> Without this, and using only the default setting :
>
> mysql_sql_mode = TRADITIONAL

Yes, this is an option in oslo.db:
http://docs.openstack.org/developer/oslo.db/opts.html#database.mysql_sql_mode

So you'll need to submit a patch here:
https://github.com/openstack/puppet-oslo/blob/master/manifests/db.pp
(with unit tests)

And here:
https://github.com/openstack/puppet-keystone/blob/master/manifests/db.pp

Cheers,

> many queries are failing in MariaDB servers
>
> MariaDB [(none)]> set session sql_mode = 'TRADITIONAL';
> Query OK, 0 rows affected (0.00 sec)
>
> MariaDB [(none)]> SHOW FULL TABLES FROM "keystone";
> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
> that corresponds to your MariaDB server version for the right syntax to use
> near '"keystone"' at line 1
> MariaDB [(none)]>
>
> Cheers,
> Alex
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

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

[openstack-dev] [ironic] static Portgroup support.

[Vasyl Saienko]

Hello Community,

Current portgroup scenario is not fully clear for me. The related spec [3]
doesn't clearly describe it. And based on implementation [1] and [2] I
guess it should work in the following fashion for node with 3 NICs, where
eth1 and eth2 are members of Porgroup Po0/1

Node network connection info:
eth1 (aa:bb:cc:dd:ee:f1) <---> Gig0/1
eth2 (aa:bb:cc:dd:ee:f2) <---> Gig0/2
eth3 (aa:bb:cc:dd:ee:f3) <---> Gig0/3

For FLAT network scenario:
1. Administrator enrol ironic node.
2. Administrator creates a 3 ports for each interface, and a portgroup that
contains eth0 and eth1 ports.
3. The ports Gig0/1 and Gig0/2 are added to portgroup Po0/1 manually on the
switch.
4. When user request to boot an instance, Nova randomly picks interface
[2], it might be a portgroup or single NIC interface. Proposed change [1]
do not allow to specify what exactly network type we would like to use
single NIC or portgroup.

For multitenancy case:
All looks the same, in addition administrator adds local_link_connection
information for each port (local_link_connection 'port_id' field is
'Gig0/1' for eth1, 'Gig0/2' for eth2 and 'Gig0/3' for eth3, ). Ironic send
this information to Neutron who plugs ports to needed network.

The same user-scenario is available at the moment without any changes to
Nova or Ironic. The difference is that administrator creates one port for
single interface eth3 with local_link_connection 'port_id'='Gig0/3',  and a
port that is a logical representation of portgroup (eth1 and eth2) with
local_link_connection 'port_id'='Po0/1'.

Please let me know if I've missed something or misunderstood current
portgroup scenario.

Reference:
[0] https://review.openstack.org/206163
[1] https://review.openstack.org/332177
[2]
https://github.com/openstack/nova/blob/06c537fbe5bb4ac5a3012642c899df815872267c/nova/network/neutronv2/api.py#L270
[3]
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance][Heat][Murano][App-Catalog][Tacker] Glare is ready for wider review

[Mikhail Fedosin]

Hello! Today I'm happy to announce that Glare's code is done and the
service is ready for review [1].

Glare (from GLance Artifact REpository) is a new service in the Glance
project that provides a secure and customizable unified binary repository
for OpenStack [2].

The idea behind Glare is to allow various OpenStack services to catalog
different binary objects they use to operate. Images used by Nova to run
the VMs are just the best known examples of such objects; other examples
include Heat templates, Tacker blueprints, Murano packages, and so on.
Obviously, this functionality is common for different kinds of objects, and
is usually unrelated to the primary mission of respective projects using
these objects. That's why we implemented a dedicated service that will take
care of managing various data assets in OpenStack clouds.

This service fills a vacant niche in OpenStack and is intended to become a
unified catalog of structured meta-information, as well as related binary
data (with these objects comprising the 'artifacts'). In general Glare
provides next key functionality, it:
  * stores the objects reliably;
  * guarantees their immutability once they're stored;
  * provides search capabilities to find objects in the catalog;
  * controls access to the objects by enforcing usage and modification
policies, sharing and publication scenarios and so on;
  * returns the detailed info about the requested objects;
  * enables fetching of objects and manages their lifecycle;
  * supports import/export the objects between clouds.

Our next steps are related to help integrate various projects with Glare
and implement artifact types for them [3]. Currently we are working with
Heat, Murano and App-Catalog teams, but if you have any binary assets you
want to catalog reliably - feel free to contact me and we will help your
project to get the same functionality like Nova gets from Glance.

Links:
[1] Glare's code top commit: https://review.openstack.org/#/c/330459/5
[2] Merged Glare API spec: https://review.openstack.org/#/c/283136/
[3] Prototype of Heat artifact type:
https://review.openstack.org/#/c/292327/46/glance/objects/heat-templates.py

Best regards.
Mikhail Fedosin
__
OpenStack Development Mailing List (not for 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][all] Big tent? (Related to Plugins for all)

[Doug Hellmann]

Excerpts from Ed Leafe's message of 2016-07-18 21:59:44 -0700:
> On Jul 18, 2016, at 12:39 PM, Fox, Kevin M  wrote:
> 
> > I'm arguing the opposite. It should be a requirement to use the OpenStack 
> > Secret Store.
> > 
> > Instead, we're trying to make it optional and either reimplementing large 
> > swaths of it in individual projects to make it optional, or skip security 
> > all together.
> > 
> > If it wasn't optional, then:
> > * Keystone could rely on it being there for password hashing
> > * Magnum can rely on it for security.
> > * lbaas can rely on it
> > * App developers can rely on it being there
> > * ...
> > 
> > Same with Zaqar. It was a requirement then,
> > * Guest agents of heat, sahara, mangum, trove, etc could all rely on it 
> > being there and wouldn't have to deal with workarounds
> > * Horizon could rely on it being there for dynamic ui
> > * App developers can rely on it being there.
> > 
> > Yes, it seems like more work for an operator to have to install "one more 
> > thing", but the savings it provides by not having to do that "one more 
> > thing" in 7 different projects pays for it.
> 
> There is a lot to be said for code simplification. When Glance split out of 
> Nova, the knowledge that Glance would be required to be there meant the the 
> code in Nova for interacting with it didn’t have to contain tons of ‘if 
> :  else ”. Knowing that that 
> code was unnecessary made writing the interaction much simpler (and less 
> tedious to read). So if we added, say, Barbican as a requirement, all of the 
> other projects that need to handle secrets (a lot of them!) could simply 
> program to the Barbican interface, and be done with it.
> 
> The discussion of whether project X should be required is a whole ‘nother 
> topic. But I want to emphasize that often the utility of having a standard is 
> grossly underestimated.
> 
> In this discussion, the issue that seems to be arising is that the Big Tent 
> doesn’t provide for a path for a project to be reconsidered as an OpenStack 
> standard, in the way that Nova and Glance and Swift are. The Small Tent 
> “incubation” process designed to identify which projects were mature enough 
> to be considered “one of us”, when “us” was the group of core projects. This 
> was unnecessarily harsh, and pushed away many worthy efforts. In an attempt 
> to improve this, the definition of “one of us” was broadened so that lots of 
> interesting projects could be part of the community.

This came up during the discussion of co-gating that was part of
the big tent implementation, IIRC we settled on the policy that
teams are encouraged to rely on the projects produced by other
community teams *when they are comfortable adding co-gating to
ensure continued compatibility*, but there was no rule that such
relationships must be put in place because we don't want projects
to depend on new, potentially unstable, services before they are
ready.

So, the nova and glance teams are currently comfortable co-gating,
and nova can therefore depend on glance being present. Projects
handling secrets would need to negotiate similar functional test
co-gating relationships with the barbican team. At that point it
would be safe to have barbican as a required dependency of those
other projects.

Doug


> 
> What I think is causing some confusion (and friction) is that OpenStack needs 
> two “us”s: what projects are part of our ecosystem and build software in the 
> same open way (the Big Tent concept), and which are a fundamental component 
> of the overall OpenStack software, which all other projects can assume are 
> available (the Small Tent concept). 
> 
> To that end, it seems necessary to define a migration path for a project to 
> become required. Of course, most will never need to be required, but I think 
> a case could be made that several projects (Barbican and Zaqar are the 
> obvious ones here) have matured to the point where it makes sense to 
> standardize on them. They are mature, and no other projects have come along 
> to challenge their designs. At some point, it makes sense to stop pretending 
> that there are options, and establish a standard instead.
> 
> 
> -- Ed Leafe
> 

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

Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

[Ryan Hallisey]

+1

-Ryan

- Original Message -
From: "Jeffrey Zhang" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, July 18, 2016 9:16:09 PM
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 to apply
I'd like to be the volunteer.

On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
 wrote:
> On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke  wrote:
>> Hi Steve,
>>
>> +1 to applying. I'll volunteer for the backport team also.
>>
>> -Paul
>>
>>
>> On 18/07/16 13:07, Steven Dake (stdake) wrote:
>>>
>>> Hey Koalians,
>>>
>>> I'd like us to consider applying  for the stable follows policy tag.
>>>   Full details are here:
>>>
>>>
>>> http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst
>>>
>>> Because of the magic work we did to make liberty functional, it is
>>> possible that we may not be able to apply for this tag until Liberty
>>> falls into EOL.  Still I personally believe intent matters most, and our
>>> intent has always been for these to be stable low-rate-of-change
>>> no-feature-backport branches.  There are some exceptions I think we
>>> would fit under for the Liberty case, so I think it is worth a shot.
>>>
>>> I'd need 2-4 people to commit to joining the stable backport team for
>>> Kolla reviews specifically.  These folks would be the only folks that
>>> could ACK patches in the stable branch maintenance queue.  Anyone could
>>> continue to submit backport patches as they desire.
>>>
>>> I'll leave voting open for 1 week or until there I a majority (6 core
>>> reviewers) or until there is a unanimous vote.  If there is not, then we
>>> won't apply.  The deadline for this vote is July 25th.
>>>
>>> Thanks!
>>> -steve
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> +1 to apply for stable follows policy.
> I would like to volunteer for the backport team.
>
> __
> OpenStack Development Mailing 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,
Jeffrey Zhang
Blog: http://xcodest.me

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

__
OpenStack Development Mailing List (not for 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-ansible] existing centralized syslog server

[fabrice grelaud]

> Le 7 juil. 2016 à 15:02, Jesse Pretorius  a 
> écrit :
> 
> On 7/6/16, 3:24 PM, "fabrice grelaud"  wrote:
> 
>> 
>> I would like to know what is the best approach to customize our 
>> openstack-ansible deployment if we want to use our existing solution of ELK 
>> and centralized rsyslog server.
>> 
>> We deploy openstack-ansible (mitaka 13.1.2 release) on our infrastructure 
>> with for convenient and no risk a vm for syslog server role. That is ok. But 
>> now if i want to use our centralized syslog server ?
>> 
>> What i need is to set ip address of our existing server to the rsyslog 
>> client (containers + metal) and of course configure our rsyslog.conf to 
>> manage openstack template.
>> So:
>> - no need to create on the log server a lxc container (setup-hosts.yml: 
>> lxc-hosts-setup, lxc-containers-create)
>> - no need to install syslog server (setup-infrastructure.yml: 
>> rsyslog-install.yml)
> 
> To add more rsyslog targets for logs you can see in 
> https://github.com/openstack/openstack-ansible-rsyslog_client/blob/stable/mitaka/defaults/main.yml#L56-L73
>  that there is an example of the changes you need to make to 
> /etc/openstack_deploy/user_variables.yml to include additional targets.

Really great… ;-)

> 
> You may be able to do away with the log host altogether as you desire by 
> simply leaving the ‘log_hosts’ group out of the 
> /etc/openstack_deploy/openstack_user_config.yml and 
> /etc/openstack_deploy/conf.d/*.yml files. This is an untested code path so 
> you may find that we make assumptions about the presence of the log_host so 
> please register bugs for any issues you find so that we can eradicate those 
> assumptions. To my mind the log host is not required for a deployment if the 
> deployer so chooses (and especially if the deployer has alternative syslog 
> targets in-place).

No issues found.
I launched the playbook setup-hosts.yml, everything good.
I tested to launch the rsyslog-install.yml playbook and i got "skipping: no 
hosts matched" as expected.

Yours assumptions look good. 

And an « openstack-ansible setup-everything.yml » with the tag « rsyslog_client 
» did the rest...  

> 
>> How can i modify my openstack-ansible environment (/etc/openstack_deploy, 
>> env.d, conf.d, openstack_user_config.yml, user_variables.yml, playbook ?) 
>> the most transparent manner and that permits minor release update simply ?
> 
> As long as you’re only editing things in user space (i.e. In 
> /etc/openstack_deploy/) and not in-tree (i.e. In /opt/openstack-ansible/) 
> then the minor upgrade process is documented here: 
> http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/app-minorupgrade.html
> 
> I hope that this answers your questions!
> 

Perfect ! Thanks a lot…

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


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

Re: [openstack-dev] [glance][nova] Globally disabling hw_qemu_guest_agent support

[Daniel P. Berrange]

On Tue, Jul 19, 2016 at 12:51:07AM +, Daniel Russell wrote:
> Hi Erno,
> 
> For the size of team I am in I think it would work well but it feels like
> I am putting the security of Nova in the hands of Glance.

Yep, from an architectural pov it is not very good. Particularly in a
multi-hypervisor compute deployment you can have the situation where yoyu
want to allow a property for one type of hypervisor but forbid it for another.

What we really need is the exact same image property security restrictions
implemented by nova-compute, so we can setup compute nodes to blacklist
certain properties.

> 
> What I was more after was a setting in Nova that says 'this hypervisor
> does not allow guest sockets and will ignore any attempt to create them',
> 'this hypervisor always creates guest sockets regardless of your choice',
> 'this hypervisor will respect whatever you throw in hw_qemu_guest_agent
> with a default of no', or 'this hypervisor will respect whatever you throw
> in hw_qemu_guest_agent with a default of yes'.  It feels like a more
> appropriate place to control and manage that kind of configuration.

Nope, there's no such facility right now - glance property protection
is the only real option. I'd be very much against adding a lockdown
which was specific to the guest agent too - if we did anything it would
be to have a generic property protection model in nova that mirrors what
glance supports.

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

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

Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

[Hayes, Graham]

On 18/07/16 22:27, Ronald Bradford wrote:
> Hi All,
>
> For Oslo libraries we ensure that API's are backward compatible for 1+ 
> releases.
> When an Oslo API adds a new class attribute (as in this example of
> is_admin_project and 4 other attributes) added to Oslo Context in
> 2.6.0,  these are added to ensure this API is also forward compatible
> with existing project code for any contract with the base class
> instantiation or manipulation.

Which projects is this run against?

> The issue seen is presently Nova specific (as other projects can
> utilize 2.6.0) and it is related to projects that sub-class
> oslo.context, and how unit tests are written for using class
> parameters.  Ideally, to implement using oslo.context correctly
> OpenStack projects should:

Designate also had to make a quick change to support 2.6.0.

We were lucky as it was noticed by the RDO builds, which had pulled in
2.6.0 before the requirements update was proposed, so it did not break
our gate.

I just did a quick search and there is a few projects that hardcoded
this, like we did.

> * Not perform direct dictionary to dictionary comparisons with the
> to_dict() method as this does not support when new attributes at
> added. Two patches (one to nova) address this in offending projects
> [5][6]
> * Unit tests should focus on attributes specific to the sub-classed
> signature, e.g. [7].  Oslo context provides an extensive set of unit
> tests for base class functionality. This is a wish list item for
> projects to implement.
>
> The to_dict() method exists as a convenience method only and is not an
> API contract. The resulting set of keys should be used accordingly.
> This is why there is no major release version.

How are developers supposed to know that?

This kind of feels like semantics. This was an external API that changed
and as a result should have been a major version.

> There is a note from our discussion in Oslo to improve our
> documentation to describe the API use of to_dict() better and state we
> will not remove to_dict() keys within a release, but that may happen
> between releases.
>
> There is a subsequent problem with how Nova performs a warning test
> [8]. Additional reviews are looking at addressing this sub-class usage
> of from_dict() and to_dict().
>
> Regards
>
> Ronald
>
>
> [5] https://review.openstack.org/#/c/343694/,
> [6] https://review.openstack.org/#/c/342367/
> [7] https://review.openstack.org/#/c/342869/
> [8] 
> http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144
>
> On Mon, Jul 18, 2016 at 10:50 AM, Matt Riedemann
>  wrote:
>> On 7/18/2016 9:42 AM, Matt Riedemann wrote:
>>>
>>> On 7/18/2016 9:09 AM, Markus Zoeller wrote:

 Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
 change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
 Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
 Portland and won't be available for the next 2h or so.
 If you can have a look at it and merge it, that would be great.

 References:
 [1]

 https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1

 [2] https://review.openstack.org/#/c/342604/1
 [3] https://bugs.launchpad.net/nova/+bug/1603979
 [4] logstash: http://goo.gl/79yFb9

>>>
>>> This is an API change for oslo.context, why wasn't it released as 3.0.0?
>>>
>>> Seems we should revert the upper-constraints bump and blacklist 2.6.0,
>>> then get that released as 3.0.0.
>>>
>>
>> Here is the blacklist:
>>
>> https://review.openstack.org/#/c/343683/
>>
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

[openstack-dev] [Openstack-operators] [puppet] [keystone] support for mysql_sql_mode

[Constantinescu David Alexandru]

Hi Guys

Do you think it's possible to add support for setting mysql_sql_mode in the
keystone puppet module?

Without this, and using only the default setting :

mysql_sql_mode = TRADITIONAL

many queries are failing in MariaDB servers

MariaDB [(none)]> set session sql_mode = 'TRADITIONAL';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SHOW FULL TABLES FROM "keystone";
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
that corresponds to your MariaDB server version for the right syntax to use
near '"keystone"' at line 1
MariaDB [(none)]>
Cheers,
Alex
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] How to enable SSL in devStack?

[Andrey Pavlov]

just add

USE_SSL=True

to your localrc before run stack.sh

Regards,
Andrey.

On Tue, Jul 19, 2016 at 10:17 AM, Wenzhi Yu (yuywz)  wrote:
> Hi folks,
>
> I want to configure the openstack endpoints to use SSL in devStack.
>
> I searched on internet and found some posts like [1] and tried the
> configuration in the post, but devStack script failed with error messages
> like:
> "Discovering versions from the identity service failed when creating the
> password plugin. Attempting to determine version from URL. Could not
> determine a suitable URL for the plugin."
> [1]https://ask.openstack.org/en/question/45348/devstack-with-ssl/
>
> So how to enable SSL in devStack? Can anyone please give me some guidance?
> Thanks!
>
> 2016-07-19
> 
> Best Regards,
> Wenzhi Yu (yuywz)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind regards,
Andrey Pavlov.

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

Re: [openstack-dev] Mascot/logo for your project

[Gerard Braad]

On Mon, Jul 11, 2016 at 11:33 PM, Steven Hardy  wrote:
> TripleO has had some discussion already around a project mascot, and we've
> settled on the owl logo displayed on tripleo.org and our launchpad org:
> (There is also a hi-res version or SVG around, I just can't find it atm)

The logo on http://tripleo.org links to the SVG as defined in
tweaks.css. The link is:

   http://tripleo.org/_static/tripleo_owl.svg


-- 

   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]

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

[Dmitry Dmitriev]

Hello All!

We have a very old bug about the Capacity table on the Dashboard tab of 
environment in Fuel:

https://bugs.launchpad.net/fuel/+bug/1375750 


Current design:

https://drive.google.com/open?id=0Bxi_JFs365mBNy1WT0xQT253SWc

It shows the full capacity (CPU/Memory/HDD) of all discovered by Fuel nodes.

New design: 

https://drive.google.com/open?id=0Bxi_JFs365mBaWZ0cUtla3N6aEU

It contains compute node CPU/Memory capacity and Ceph disk capacity only.

New design pros:
- cloud administrator can easily estimate all available resources for cloud 
instances

New design cons:
- if cloud doesn’t use Ceph then HDD value is zero

What do you think about the new design?

With best regards, Dmitry

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

Re: [openstack-dev] Mascot/logo for your project

[Julien Danjou]

On Sat, Jul 16 2016, Thierry Carrez wrote:

> Julien Danjou wrote:
>> Something is very unclear (but I'm getting used to it lol): are theses
>> logo created for projects or teams?
>>
>> We have 4 different projects (Aodh, Gnocchi, Ceilometer & Panko) in the
>> Telemetry team. Should we have one or 4 mascots?
>
> Heidi will likely confirm, but my understanding is that it's a mascot per 
> team,
> not per deliverable within that team. So in your case that would be the
> "Telemetry" mascot.

Heidi, could you confirm that it is a mascot per team or per project?

Honestly, I don't think it'll suit us to have only one mascot/logo. It's
gonna be hard to use a logo marked "Telemetry" as a branding for our 4
different projects that do different things – even if it's in the same
area.

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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] [all] Reviewing coverage jobs set up

[Julien Danjou]

On Mon, Jul 18 2016, Andreas Jaeger wrote:

> While looking at coverage jobs to enable them to allow use of
> constraints in post jobs (something which has just been introduced and
> needs some more testing before we take on the other jobs), I noticed
> that we have quite a few coverage
> jobs that are failing.

I had no idea these jobs existed and we never used them. So I think it's
safe to disable them for telemetry projects and save some CPU time from
the gate for other things.

(Not saying the info is useless, but as far as we're concern, running it
From time to time locally and trying to check what might not be covered
is largely good enough.)

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

[Julien Danjou]

On Mon, Jul 18 2016, Joshua Harlow wrote:

> Thus why I think the starting of the architecture working group is a good
> thing; because I have a believe that people are forgetting among all of this
> that such a group holds a lot of the keys to the kingdom (whether u, the
> reader, want to admit that or not is well the readers problem) in openstack
> (sorry and no disrespect to independent folks & contributors), but most of us
> work for large companies that have architects (and leads) and if those
> architects (and leads) can get together cross-company to aggregate and (agree
> on) and solve actual problems then that really is IMHO the only way to keep 
> our
> projects healthy (assuming we can even do that at this stage).

I think it is a bit naive to think any working group is going to fix
architectural problems. You know first hand what happened¹ with the Nova
service group and tooz for example.

¹  Nothing.

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


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

[openstack-dev] [devstack] How to enable SSL in devStack?

[Wenzhi Yu (yuywz)]

Hi folks,

I want to configure the openstack endpoints to use SSL in devStack.

I searched on internet and found some posts like [1] and tried the 
configuration in the post, but devStack script failed with error messages like:
"Discovering versions from the identity service failed when creating the 
password plugin. Attempting to determine version from URL. Could not determine 
a suitable URL for the plugin."
[1]https://ask.openstack.org/en/question/45348/devstack-with-ssl/

So how to enable SSL in devStack? Can anyone please give me some guidance? 
Thanks!

2016-07-19



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

Re: [openstack-dev] [grenade] upgrades vs rootwrap

[Thierry Carrez]

Sean Dague wrote:

On 07/04/2016 05:36 AM, Sean McGinnis wrote:

On Mon, Jul 04, 2016 at 01:59:09PM +0200, Thierry Carrez wrote:
[...]

The issue here is that oslo.rootwrap uses config files to determine
what to allow, but those are not really configuration files as far
as the application using them is concerned. Those must match the
code being executed.

So from Grenade perspective, those should really not be considered
configuration files, but application files.

[...]

+1

I have to agree with this perspective. They are config files, but they
are a special type of config file that is closely tied in to the code. I
think we should treat them as application files.

I say we allow these changes for grenade and move forward on this. I
think we all agree we want to move to privsep. As long as we document
this very clearly that these changes need to be made for upgrades, I'm
OK with that.

I would really like to be able to decided on this and move forward. I'm
afraid sticking with rootwrap for another cycle with just confuse things
and compound our issues.


So, can we just put them in python code inline then and abandon etc?

Special config files that we don't want anyone to touch, but we put in
/etc, aren't really a thing. You really can't have it both ways. Either
these are in the part of the filesystem where ops expect to change them,
or they are not.


Totally. As I said elsewhere in this thread, most distros are shipping 
them under /usr/share/, and oslo.rootwrap by default loads them 
from there as well. The only reason it (also) loads filters from 
/etc/ is that we wanted to let users *add* their own filters 
for their own extra plugin code. So I would argue that the right call is 
for devstack to deploy them in /usr/share/ (where they would 
just upgrade in place at the same time the code is updated) ?


Loading them from Python code inline would require more significant 
changes (including moving them in all projects, changing rootwrap to 
support inline filter loading and a min version bump everywhere...)


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

[Alex Xu]

2016-07-18 13:45 GMT-07:00 Matt Riedemann :

> On 7/15/2016 8:06 PM, Alex Xu wrote:
>
>>
>> Actually I still think aggregates isn't good for Manage Caps, just as I
>> said in previous reply about Aggregates. One of reason is just same with
>> #2 you said :) And It's totally not managable. User is even no way to
>> query a specific host in which host-aggregate. And there isn't a
>> interface to query what metadata was related to the host by
>> host-aggregate. I prefer just keep the Aggregate as tool to group the
>> hosts. But yes, user still can use host-aggregate to manage host with
>> old way, let's user decide what is more convenient.
>>
>>
> +1 to Alex's point. I just read through this thread and had the same
> thought. If the point is to reduce complexity in the system and surface
> capabilities to the end user, let's do that with resource provider tags,
> not a mix of host aggregate metadata and resource provider tags so that an
> operator has to set both, but also know in what situations he/she has to
> set it and where.
>
> I'm hoping Jay or someone channeling Jay can hold my hand and walk me
> safely through the evil forest that is image properties / flavor extra
> specs / scheduler hints / host aggregates / resource providers / and the
> plethora of scheduler filters that use them to build a concrete
> picture/story tying this all together. I'm thinking like use cases, what
> does the operator need to do, what does the end user of the cloud need to
> do, etc. I think if we're going to do resource providers tags for
> capabilities we also need to think about what we're replacing. Maybe that's
> just host aggregate metadata, but what's the deprecation plan for that?
>

Yes, it is a lot of confuse on existed image properties and extra_specs. I
have tried list all the properties and extra_specs:
https://etherpad.openstack.org/p/nova_existed_extra_spec_and_metadata

But look at them, I think none of them are capabilities(after Jay point me
out the disk_type isn't capabilities). They are very hypervisor specific or
VM hardware configuration detail.

The Nova API shouldn't expose any specific hypervisor detail, also the VM
hardware configuration detail. User shouldn't care about those detail, they
just needs request the Capabilities, then nova decide the VM hardware
configuration based on the Capabilities.

My initial thought is we leave the existed properties and extra_specs
alone, deal with Capabilities separately. Just dump my thought at here.

For the deprecation of host aggregate metadata, I didn't thought that yet.
In normally we can keep them for a release after we have ResourceTags?
Anyway I will think about it more, thanks for point this out.



>
> There is a ton to talk about here, so I'll leave that for the midcycle.
> But let's think about what, if anything, needs to land in Newton to enable
> us working on this in Ocata - but our priority for the midcycle is really
> going to be focused on what things we need to get done yet in Newton based
> on what we said we'd do in Austin.
>
> Also, a final nit - can we please be specific about roles in this thread
> and any specs? I see 'user' thrown around a lot, but there are different
> kinds of users. Only admins can see host aggregates and their metadata. And
> when we're talking about how these tags will be used, let's be clear about
> who the actors are - admins or cloud users. It helps avoid some confusion.


Got it, I will clear the user roles in the specs later. Thanks for point
this out too.


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