Re: [openstack-dev] [neutron][tc] Neutron stadium evolution from Austin

2016-05-05 Thread Fawad Khaliq
Armando has submitted the proposal on Gerrit [1]. Let's take the discussion
there.

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

Fawad Khaliq


On Tue, May 3, 2016 at 2:37 AM, Doug Wiegley 
wrote:

> Were we looking at the same etherpad?  I think the ‘inclusion criteria’
> and ‘benefits of the proposal’ sections cover those two points. Are you
> referring to something else?
>
> Thanks,
> doug
>
>
> On May 2, 2016, at 12:18 PM, Gal Sagie  wrote:
>
> Maybe it can help if instead of trying to define criteria to which
> projects dont fit into
> the stadium, try to define in your spec what IT IS, and for what purpose
> its there.
>
>
> On Mon, May 2, 2016 at 8:53 PM, Kyle Mestery  wrote:
>
>> On Mon, May 2, 2016 at 12:22 PM, Armando M.  wrote:
>> >
>> >
>> > On 30 April 2016 at 14:24, Fawad Khaliq  wrote:
>> >>
>> >> Hi folks,
>> >>
>> >> Hope everyone had a great summit in Austin and got back safe! :)
>> >>
>> >> At the design summit, we had a Neutron stadium evolution session, which
>> >> needs your immediate attention as it will impact many stakeholders of
>> >> Neutron.
>> >
>> >
>> > It's my intention to follow up with a formal spec submission to
>> > neutron-specs as soon as I recover from the trip. Then you'll have a
>> more
>> > transparent place to voice your concern.
>> >
>> >>
>> >>
>> >> To summarize for everyone, our Neutron leadership made the following
>> >> proposal for the “greater-good” of Neutron to improve and reduce
>> burden on
>> >> the Neutron PTL and core team to avoid managing more Neutron drivers:
>> >
>> >
>> > It's not just about burden. It's about consistency first and foremost.
>> >
>> >>
>> >>
>> >> Quoting the etherpad [1]
>> >>
>> >> "No request for inclusion are accepted for projects focussed solely on
>> >> implementations and/or API extensions to non-open solutions."
>> >
>> >
>> > By the way, this was brought forward and discussed way before the
>> Summit. In
>> > fact this is already implemented at the Neutron governance level [1].
>> >
>> >>
>> >> To summarize for everyone what this means is that all Neutron drivers,
>> >> which implement non open source networking backends are instantly out
>> of the
>> >> Neutron stadium and are marked as "unofficial/unsupported/remotely
>> >> affiliated" and rest are capable of being tagged as
>> "supported/official”.
>> >
>> >
>> > Totally false.
>> >
>> > All this means is that these projects do not show up in list [1] (minus
>> [2],
>> > which I forgot): ie. these projects are the projects the Neutron team
>> > vouches for. Supportability is not a property tracked by this list. You,
>> > amongst many, should know that it takes a lot more than being part of a
>> list
>> > to be considered a supported solution, and I am actually even surprised
>> that
>> > you are misled/misleading by bringing 'support' into this conversation.
>> >
>> > [1] http://governance.openstack.org/reference/projects/neutron.html
>> > [2] https://review.openstack.org/#/c/309618/
>> >
>> >>
>> >>
>> >> This eliminates all commercial Neutron drivers developed for many
>> service
>> >> providers and enterprises who have deployed OpenStack successfully with
>> >> these drivers. It’s unclear how the OpenStack Foundation will
>> communicate
>> >> its stance with all the users but clearly this is a huge set back for
>> >> OpenStack and Neutron. Neutron will essentially become closed to all
>> >> existing, non-open drivers, even if these drivers have been compliant
>> with
>> >> Neutron API for years and users have them deployed in production,
>> forcing
>> >> users to re-evaluate their options.
>> >
>> >
>> > Again, totally false.
>> >
>> > The Neutron team will continue to stand behind the APIs and integration
>> > mechanisms in a way that made the journey of breaking down the codebase
>> as
>> > we know it today possible. Any discussion of evolving these has been
>> done
>> > and will be done in the open and with the support of all parties
>> involved,
>> > non-open solutions included.
>> >
>> >>
>> >>
>> >> Furthermore, this proposal will erode confidence in Neutron and
>> OpenStack,
>> >> and destroy much of the value that the community has worked so hard to
>> build
>> >> over the years.
>> >>
>> >>
>> >> As a representative and member of the OpenStack community and
>> maintainer
>> >> of a Neutron driver (since Grizzly), I am deeply disappointed and
>> disagree
>> >> with this statement [2]. Tossing out all the non-open solutions is not
>> in
>> >> the best interest of the end user companies that have built working
>> >> OpenStack clusters. This proposal will lead OpenStack end users who
>> deployed
>> >> different drivers to think twice about OpenStack communities’
>> commitment to
>> >> deliver solutions they need. Furthermore, this proposal punishes
>> OpenStack
>> >> companies who developed commercial backend drivers to help end users
>> bring
>> 

Re: [openstack-dev] [tricircle] Easy Way to Test Tricircle North-South L3 Networking

2016-05-05 Thread Shinobu Kinjo
Hi Team,

If a main problem is a number of network interfaces (I guess it's a
problem), here is more eco solution.
In side your linux box, you can add virtual network interfaces with
multiple subnets.
It's not related to this project. But it may be better to show the
followings for someone who are interested in this project.

0. Create VMs and add virtual interfaces no matter what you want.

1. Create configuration files.
 * A number of files are up to your requirement.
 * In this scenario, ens9 and ens10 are new.

[root@bottom01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
HWADDR=52:54:00:7D:1A:6B
TYPE=Ethernet
BOOTPROTO=dhcp

[root@bottom01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens10
DEVICE=ens10
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=none
IPADDR=1.0.1.1
NETMASK=255.255.255.0

[root@bottom01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens11
DEVICE=ens11
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=none
IPADDR=1.0.2.1
NETMASK=255.255.255.0

2. Modify routing table
[root@localhost ~]# cat /etc/iproute2/rt_tables
[snip]
100 t1
101 t2
[snip]

3. Set default gateway for additional interfaces
[root@localhost ~]# cat /etc/rc.local
[snip]
# It's up to above settings
ip route add 1.0.1.0/24 dev ens10 src 1.0.1.1 table t1
ip route add table t1 default via 172.16.0.254 dev ens10

ip route add 1.0.2.0/24 dev ens11 src 1.0.2.1 table t2
ip route add table t2 default via 172.16.0.254 dev ens11

ip rule add table t1 from 1.0.1.1
ip rule add table t2 from 1.0.2.1

4. Set arp settings for additional interfaces
[root@localhost ~]# cat /etc/sysctl.d/arp.conf
net.ipv4.conf.all.filter = 1
net.ipv4.conf.default.filter = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2

5. Check ips
[root@bottom01 ~]# ip a | egrep 'eth|ens' | grep inet
inet 1.0.1.1/24 brd 1.0.1.255 scope global ens10
inet 1.0.2.1/24 brd 1.0.2.255 scope global ens11
inet 172.16.0.79/24 brd 172.16.0.255 scope global dynamic eth0

# Repeat 1 ~ 4, if necessary

6. Make sure network connectivity between hosts on additional network address
* bottom01
[root@bottom01 ~]# ip a | egrep 'eth|ens' | grep inet
inet 1.0.1.1/24 brd 1.0.1.255 scope global ens10
inet 1.0.2.1/24 brd 1.0.2.255 scope global ens11
inet 172.16.0.79/24 brd 172.16.0.255 scope global dynamic eth0

* bottom02
[root@bottom02 ~]# ip a | egrep 'eth|ens' | grep inet
inet 1.0.1.2/24 brd 1.0.1.255 scope global ens9
inet 1.0.2.2/24 brd 1.0.2.255 scope global ens10
inet 172.16.0.78/24 brd 172.16.0.255 scope global dynamic eth0

[root@bottom02 ~]# ping 1.0.1.1
PING 1.0.1.1 (1.0.1.1) 56(84) bytes of data.
64 bytes from 1.0.1.1: icmp_seq=1 ttl=64 time=0.502 ms
64 bytes from 1.0.1.1: icmp_seq=2 ttl=64 time=0.267 ms
64 bytes from 1.0.1.1: icmp_seq=3 ttl=64 time=0.366 ms
64 bytes from 1.0.1.1: icmp_seq=4 ttl=64 time=0.390 ms
64 bytes from 1.0.1.1: icmp_seq=5 ttl=64 time=0.335 ms

[root@bottom01 ~]# tcpdump -i ens10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens10, link-type EN10MB (Ethernet), capture size 65535 bytes
00:53:59.873858 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
7, length 64
00:53:59.873886 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
7, length 64
00:54:00.835425 STP 802.1d, Config, Flags [none], bridge-id
8000.8c:dc:d4:32:63:ad.8005, length 43
00:54:00.873897 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
8, length 64
00:54:00.873926 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
8, length 64
00:54:01.873828 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
9, length 64
00:54:01.873855 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
9, length 64
00:54:02.835464 STP 802.1d, Config, Flags [none], bridge-id
8000.8c:dc:d4:32:63:ad.8005, length 43
00:54:02.873849 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
10, length 64
00:54:02.873879 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
10, length 64
00:54:03.873843 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
11, length 64
00:54:03.873871 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
11, length 64
00:54:04.835573 STP 802.1d, Config, Flags [none], bridge-id
8000.8c:dc:d4:32:63:ad.8005, length 43
00:54:04.873870 IP 1.0.1.2 > bottom01: ICMP echo request, id 2909, seq
12, length 64
00:54:04.873899 IP bottom01 > 1.0.1.2: ICMP echo reply, id 2909, seq
12, length 64

Cheers,
S

On Wed, May 4, 2016 at 11:17 AM, joehuang  wrote:
> Hi, Shinobu,
>
> Correct, this is not the normal deployment scenario and the way of testbed 
> setup.
>
> Cheers
>
> BR
> Chaoyi Huang ( joehuang )
>
> 
> From: Shinobu Kinjo [shinobu...@gmail.com]
> Sent: 04 May 2016 9:38
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tricircle] Easy Way to Test Tricircle 
> North-South L3 Networking
>
> Hi Chaoyi,
>
> I didn't consider Ronghui's environment which I have no idea about.
>
>> 

Re: [openstack-dev] [app-catalog] [glare] [murano] [mistral] Austin summit summary: Community App Catalog

2016-05-05 Thread Renat Akhmerov

> On 06 May 2016, at 03:00, Christopher Aedo  wrote:
> 
> On Wed, May 4, 2016 at 9:15 PM, Renat Akhmerov  
> wrote:
> > Cool, feel free to communicate with us on adding Mistral assets into the
> > catalog.
> 
> Of course!  We started a blueprint for the related tasks[1] and hopefully 
> myself or someone from the Mistral team will be able to take a few of the 
> first steps soon.  I think Mistral workflows would be a really useful 
> addition to the Community App Catalog so I'm excited to drive this effort.
> 
> One of the sessions I saw at the summit really impressed me.  "Using 
> OpenStack to clean up after itself"[2] was really cool to see.  Is that 
> example worflow used during the demo available somewhere?


Yes, that was an awesome presentation. For now, it’s an internal IBM effort but 
Todd Johnson from IBM now wants to contribute notification event trigger into 
Mistral so that everybody could do similar cool stuff based on OpenStack 
events. The spec is being discussed at [1].

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

Renat Akhmerov
@Nokia

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


Re: [openstack-dev] [Congress] Austin recap

2016-05-05 Thread Eric K
Thanks for the summary, Tim. Very productive summit!

I¹ve added more notes and a diagram to the HA ether pad. Is that the best
way to continue the discussion?
https://etherpad.openstack.org/p/newton-congress-availability


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

Date:  Tuesday, May 3, 2016 at 11:37 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  [openstack-dev] [Congress] Austin recap

> Hi all,
> 
> 
> Here¹s a quick summary of the Congress activities in Austin.  Everyone should
> feel free to chime in with corrections and things I missed.
> 
> 
> 1. Talks
> Masahito gave a talk on applying Congress for fault recovery in the context of
> NFV.
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/7199
> 
> 
> 
> Fabio gave a talk on applying Congress + Monasca to enforce application-level
> SLAs.
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/7363
> 
> 
> 
> 2. Integrations
> We had discussions, both within the Congress Integrations fishbowl session,
> and outside of that session on potential integrations with other OpenStack
> projects.  Here's a quick overview.
> 
> 
> - Monasca (fabiog). The proposed integration: Monasca pushes data to Congress
> using the push driver to let Congress know about the alarms Monasca
> configured.  Can use multiple alarms using a single table.  Eventually we
> talked about having Congress analyze the policy to configure the alarms that
> Monasca uses, completing the loop.
> 
> 
> - Watcher (acabot). Watcher aims to optimize the placement of VMs by pulling
> data from Ceilometer/Monasca and Nova (including affinity/anti-affinity info),
> computing necessary migrations for whichever strategy is configured, and
> migrates the VMs.  Want to use Congress as a source of policies that they take
> into account when computing the necessary migrations.
> 
> 
> - Nova scheduler.  There¹s interest in policy-enabling the Nova scheduler, and
> then integrating that with Congress in the context of delegation, both to give
> Congress the ability to pull in the scheduling policy and to push the
> scheduling policy.
> 
> 
> - Mistral.  The use case for this integration is to help people create an HA
> solution for VMs.  So have Congress monitor VMs, identify when they have
> failed, and kick off a Mistral workflow to resurrect them.
> 
> 
> - Vintrage.  Vintrage does root-cause-analysis.  It provides a graph-based
> model for the structure of the datacenter (switches attached to hypervisors,
> servers attached to hypervisors, etc.) and a templating language for defining
> how to create new alarms from existing alarms.  The action item that we left
> is that the Vintrage team will initiate a mailing list thread where we discuss
> which Vintrage data might be valuable for Congress policies.
> 
> 
> 3. Working sessions
> - The new distributed architecture is nearing completion.  There seems to be 1
> blocker for having the basic functionality ready to test: at boot, Congress
> doesn¹t properly spin up datasources that have already been configured in the
> database.  As an experiment to see how close we were to completion, we started
> up the Congress server with just the API and policy engine and saw the basics
> actually working!  When we added the datasources, we found a bug where the API
> was assuming the datasources could be referenced by UUID, when in fact they
> can only be referenced by Name on the message-bus.   So while there¹s still
> quite a bit to do, we¹re getting close to having all the basics working.
> 
> 
> - We made progress on the high-availability and high-throughput design.  This
> is still very much open to design and discussion, so continuing the design on
> the mailing list would be great.  Here are the highlights.
> o  Policy engine: split into (i) active-active for queries to deal with
> high-throughput (ii) active-passive for action-execution (requiring
> leader-election, etc.).  Policy CRUD modifies DB; undecided whether API also
> informs all policy-engines, or whether they all sync from the DB.
> o  Pull datasources: no obvious need for replication, since they restart
> really fast and will just re-pull the latest data anyhow
> o  Push datasources: Need HA for ensuring the pusher can always push, e.g.
> the pusher drops the message onto oslo-messaging.  Still up for debate is
> whether we also need HA for storing the data since there is no way to ask for
> it after a restart; one suggestion is that every datasource must allow us to
> ask for the state.  HT does not require replication, since syncing the state
> between several instances would be required and would be less performant than
> a 

Re: [openstack-dev] [tricircle] About the dynamic pod binding

2016-05-05 Thread Yipei Niu
Got it with thanks.

Best regards,
Yipei

On Fri, May 6, 2016 at 9:48 AM, joehuang  wrote:

> Hi, Yipei,
>
> Shinobu is correct, this should be taken into consideration in the design
> of dynamic pod binding.
>
> How to schedule pod, you can refer to host-aggregate scheduling with
> flavor, the difference is that the scheduling granularity is on pod level.
> By the tag in flavor extra-spec and volume type extrac_spec , tricircle can
> be aware of which type of resource the tenant wants to provision.
>
> For example:
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Configuration_Reference_Guide/host-aggregates.html
>
> So in
> https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit,
> one field called resource_affinity_tag is proposed to be added into the pod
> table, it could be used for scheduling purpose. But this is only one
> proposal, you may have better idea to do that, after the spec is reviewed
> and approved, the doc can be update to reflect the new idea.
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: Shinobu Kinjo [mailto:shinobu...@gmail.com]
> Sent: Friday, May 06, 2016 8:06 AM
> To: Yipei Niu
> Cc: OpenStack Development Mailing List (not for usage questions);
> joehuang; Zhiyuan Cai; 金城 忍
> Subject: Re: [tricircle] About the dynamic pod binding
>
> Hi Yipei,
>
> On Thu, May 5, 2016 at 9:54 PM, Yipei Niu  wrote:
> > Hi, all,
> >
> > For dynamic pod binding, I have some questions.
> >
> [snip]
> > 3. How is Tricircle aware of what type of resource wanted by tenants?
> > For example, a tenant wants to boot VMs for CAD modelling with
> > corresponding flavor. But in current code, the flavorRef is not get
> > involved in function get_pod_by_az_tenant, when querying pod bindings.
> > So do we need to modify the pod binding table to add such a column?
>
> Working through code bases, probably you are talking about future
> implementation, I guess.
>
> Cheers,
> Shinobu
>
> >
> > Best regards,
> > Yipei
>
>
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][FWaaS] __init__ arguments issue status

2016-05-05 Thread Doug Wiegley
This break is almost certainly because of the following neutron change, to 
unwind the incestuous inheritance that was in neutron (dependency arrow was 
circular):

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


I don’t expect there will be a lot of appetite to revert that, so it will need 
to be addressed in neutron-fwaas. Likely it should’ve had an ML warning first, 
sorry about that, this has been a longstanding issue.

doug



> On May 5, 2016, at 7:00 PM, Frances, Margaret 
>  wrote:
> 
> Hi Doug.  
> 
> The old and new MROs are both pretty complicated, and it’s not entirely clear 
> to me yet why the original one worked. (The MROs are included below for 
> reading pleasure; they're embellished to show the incoming args to self’s 
> init and outgoing args to super’s init in each case.)
> 
> I’m fairly sure the APIs for the mixins can be made the same, and I’ll try 
> that.  But I still wonder if in fact the problem is a base class ordering 
> issue.  
> 
> The error that 223343 produced occurs in method call #6 in the "AFTER" MRO, 
> where we get the following trace:
> 
>   super(PeriodicTasks, self).__init__()
> TypeError: __init__() takes exactly 2 arguments (1 given)
> 
> 
> For grins, we changed PeriodicTasks’s call to super init as suggested by the 
> trace:
> 
>   super(PeriodicTasks, self).__init__(conf)
> 
> 
> At this point FWaaSAgentRpcCallbackMixin (AFTER, #8) complained:
> 
>   super(FWaaSAgentRpcCallbackMixin, self).__init__(host)
> TypeError: object.__init__() takes no parameters
> 
> 
> Changing *that* class as suggested elicited the following (to me baffling) 
> result:
> 
>   super(FWaaSAgentRpcCallbackMixin, self).__init__()
> TypeError: __init__() takes exactly 2 arguments (1 given)
> 
> 
> I find it baffling because FWaaSAgentRpcCallbackMixin is the end of the line, 
> it’s a subclass of object, and object doesn’t allow arguments to init (so 
> whose init is that? that’s the next thing I’m going to look at).  (It’s for 
> these same reasons that I don’t understand why things worked before the 
> 223343 change.)
> 
> I’m still looking at things.  (And learning about MRO, which I’ve never 
> really dealt with before.)  Will run pdb and see what surfaces.  
> 
> Thanks for your help.  Thoughts, comments, suggestions all welcome.
> Margaret
> 
> 
> BEFORE 223343
>  1. varmour_router_vArmourL3NATAgent  (host, conf)-->(host, conf)
>  2. agent_L3NATAgent  (host, conf)-->(conf)
>  3. firewall_l3_agent_FWaaSL3AgentRpcCallback (conf)-->(host)
>  4. api_FWaaSAgentRpcCallbackMixin(host)-->(host)
>  5. ha_AgentMixin (host)-->(host)
>  6. dvr_AgentMixin(host)-->(host)
>  7. manager_Manager   (host)-->(conf)
>  8. periodic_task_PeriodicTasks   (conf)-->()
>  9. firewall_l3_agent_FWaaSL3AgentRpcCallback (conf)-->(host)
> 10. api_FWaaSAgentRpcCallbackMixin(host)-->(host)
> 11. object
> 
> AFTER 223343
>  1. varmour_router_vArmourL3NATAgent  (host, conf)-->(host, conf)
>  2. agent_L3NATAgent  (host, conf)-->(host)
>  3. ha_AgentMixin (host)-->(host)
>  4. dvr_AgentMixin(host)-->(host)
>  5. manager_Manager   (host)-->(conf)
>  6. periodic_task_PeriodicTasks   (conf)-->()
>  7. firewall_l3_agent_FWaaSL3AgentRpcCallback (conf)-->(host)
>  8. api_FWaaSAgentRpcCallbackMixin(host)-->(host)
>  9. object
> 
> --
> Margaret Frances
> Eng 4, Prodt Dev Engineering
> 
> 
> 
>> On May 5, 2016, at 7:06 PM, Doug Hellmann > > wrote:
>> 
>> Excerpts from Nate Johnston's message of 2016-05-05 17:40:13 -0400:
>>> FWaaS team,
>>> 
>>> After a day of looking at the tests currently failing in the FWaaS repo, I
>>> believe I have the issue narrowed down considerably. First, to restate what
>>> is going on.  If you check out the neutron-fwaas repository and run `tox -e
>>> py27` in it, you will get six errors all in the
>>> neutron_fwaas.tests.unit.services.firewall.agents.varmour.test_varmour_router.TestVarmourRouter
>>> section.
>>> Running the py34 tests results in similar problems.  The failures follow
>>> the following form:
>>> 
>>> Captured traceback:
>>> 
>>> ~~~
>>> 
>>>Traceback (most recent call last):
>>> 
>>>  File
>>> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
>>> line 190, in test_agent_external_gateway
>>> 
>>>router = self._create_router()
>>> 
>>>  File
>>> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
>>> line 87, in _create_router
>>> 
>>>router = varmour_router.vArmourL3NATAgent(HOSTNAME, self.conf)
>>> 
>>>  File
>>> 

Re: [openstack-dev] [tricircle] About the dynamic pod binding

2016-05-05 Thread joehuang
Hi, Yipei,

Shinobu is correct, this should be taken into consideration in the design of 
dynamic pod binding.

How to schedule pod, you can refer to host-aggregate scheduling with flavor, 
the difference is that the scheduling granularity is on pod level. By the tag 
in flavor extra-spec and volume type extrac_spec , tricircle can be aware of 
which type of resource the tenant wants to provision.

For example: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Configuration_Reference_Guide/host-aggregates.html

So in 
https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g/edit,
 one field called resource_affinity_tag is proposed to be added into the pod 
table, it could be used for scheduling purpose. But this is only one proposal, 
you may have better idea to do that, after the spec is reviewed and approved, 
the doc can be update to reflect the new idea.

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Shinobu Kinjo [mailto:shinobu...@gmail.com] 
Sent: Friday, May 06, 2016 8:06 AM
To: Yipei Niu
Cc: OpenStack Development Mailing List (not for usage questions); joehuang; 
Zhiyuan Cai; 金城 忍
Subject: Re: [tricircle] About the dynamic pod binding

Hi Yipei,

On Thu, May 5, 2016 at 9:54 PM, Yipei Niu  wrote:
> Hi, all,
>
> For dynamic pod binding, I have some questions.
>
[snip]
> 3. How is Tricircle aware of what type of resource wanted by tenants? 
> For example, a tenant wants to boot VMs for CAD modelling with 
> corresponding flavor. But in current code, the flavorRef is not get 
> involved in function get_pod_by_az_tenant, when querying pod bindings. 
> So do we need to modify the pod binding table to add such a column?

Working through code bases, probably you are talking about future 
implementation, I guess.

Cheers,
Shinobu

>
> Best regards,
> Yipei



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


Re: [openstack-dev] [Cinder] Nominating Michał Dulko to Cinder Core

2016-05-05 Thread Huang Zhiteng
+1, Michal has been contributing good quality code and reivew since he got
involved with Cinder.  It's great to have him as core.
On May 6, 2016 8:56 AM, "Alex Meade"  wrote:

+1 I thought he was already! which is usually a good sign.

On Thu, May 5, 2016 at 1:39 PM, Mike Perez  wrote:

> On 13:16 May 03, Sean McGinnis wrote:
> > Hey everyone,
> >
> > I would like to nominate Michał Dulko to the Cinder core team. Michał's
> > contributions with both code reviews [0] and code contributions [1] have
> > been significant for some time now.
>
> +1 welcome!
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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


Re: [openstack-dev] [neutron][FWaaS] __init__ arguments issue status

2016-05-05 Thread Frances, Margaret
Hi Doug.

The old and new MROs are both pretty complicated, and it’s not entirely clear 
to me yet why the original one worked. (The MROs are included below for reading 
pleasure; they're embellished to show the incoming args to self’s init and 
outgoing args to super’s init in each case.)

I’m fairly sure the APIs for the mixins can be made the same, and I’ll try 
that.  But I still wonder if in fact the problem is a base class ordering issue.

The error that 223343 produced occurs in method call #6 in the "AFTER" MRO, 
where we get the following trace:

super(PeriodicTasks, self).__init__()
TypeError: __init__() takes exactly 2 arguments (1 given)


For grins, we changed PeriodicTasks’s call to super init as suggested by the 
trace:

super(PeriodicTasks, self).__init__(conf)


At this point FWaaSAgentRpcCallbackMixin (AFTER, #8) complained:

super(FWaaSAgentRpcCallbackMixin, self).__init__(host)
TypeError: object.__init__() takes no parameters


Changing *that* class as suggested elicited the following (to me baffling) 
result:

super(FWaaSAgentRpcCallbackMixin, self).__init__()
TypeError: __init__() takes exactly 2 arguments (1 given)


I find it baffling because FWaaSAgentRpcCallbackMixin is the end of the line, 
it’s a subclass of object, and object doesn’t allow arguments to init (so whose 
init is that? that’s the next thing I’m going to look at).  (It’s for these 
same reasons that I don’t understand why things worked before the 223343 
change.)

I’m still looking at things.  (And learning about MRO, which I’ve never really 
dealt with before.)  Will run pdb and see what surfaces.

Thanks for your help.  Thoughts, comments, suggestions all welcome.
Margaret


BEFORE 223343
 1. varmour_router_vArmourL3NATAgent(host, conf)-->(host, conf)
 2. agent_L3NATAgent(host, conf)-->(conf)
 3. firewall_l3_agent_FWaaSL3AgentRpcCallback   (conf)-->(host)
 4. api_FWaaSAgentRpcCallbackMixin  (host)-->(host)
 5. ha_AgentMixin   (host)-->(host)
 6. dvr_AgentMixin  (host)-->(host)
 7. manager_Manager (host)-->(conf)
 8. periodic_task_PeriodicTasks (conf)-->()
 9. firewall_l3_agent_FWaaSL3AgentRpcCallback   (conf)-->(host)
10. api_FWaaSAgentRpcCallbackMixin  (host)-->(host)
11. object

AFTER 223343
 1. varmour_router_vArmourL3NATAgent(host, conf)-->(host, conf)
 2. agent_L3NATAgent(host, conf)-->(host)
 3. ha_AgentMixin   (host)-->(host)
 4. dvr_AgentMixin  (host)-->(host)
 5. manager_Manager (host)-->(conf)
 6. periodic_task_PeriodicTasks (conf)-->()
 7. firewall_l3_agent_FWaaSL3AgentRpcCallback   (conf)-->(host)
 8. api_FWaaSAgentRpcCallbackMixin  (host)-->(host)
 9. object

--
Margaret Frances
Eng 4, Prodt Dev Engineering



> On May 5, 2016, at 7:06 PM, Doug Hellmann  wrote:
> 
> Excerpts from Nate Johnston's message of 2016-05-05 17:40:13 -0400:
>> FWaaS team,
>> 
>> After a day of looking at the tests currently failing in the FWaaS repo, I
>> believe I have the issue narrowed down considerably. First, to restate what
>> is going on.  If you check out the neutron-fwaas repository and run `tox -e
>> py27` in it, you will get six errors all in the
>> neutron_fwaas.tests.unit.services.firewall.agents.varmour.test_varmour_router.TestVarmourRouter
>> section.
>> Running the py34 tests results in similar problems.  The failures follow
>> the following form:
>> 
>> Captured traceback:
>> 
>> ~~~
>> 
>>Traceback (most recent call last):
>> 
>>  File
>> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
>> line 190, in test_agent_external_gateway
>> 
>>router = self._create_router()
>> 
>>  File
>> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
>> line 87, in _create_router
>> 
>>router = varmour_router.vArmourL3NATAgent(HOSTNAME, self.conf)
>> 
>>  File
>> "neutron_fwaas/services/firewall/agents/varmour/varmour_router.py", line
>> 54, in __init__
>> 
>>super(vArmourL3NATAgent, self).__init__(host, conf)
>> 
>>  File "/home/njohns002/
>> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/agent.py",
>> line 244, in __init__
>> 
>>super(L3NATAgent, self).__init__(host=self.conf.host)
>> 
>>  File "/home/njohns002/
>> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/ha.py",
>> line 93, in __init__
>> 
>>super(AgentMixin, self).__init__(host)
>> 
>>  File "/home/njohns002/
>> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/dvr.py",
>> line 30, in __init__
>> 
>>super(AgentMixin, self).__init__(host)
>> 
>> 

Re: [openstack-dev] [Cinder] Nominating Michał Dulko to Cinder Core

2016-05-05 Thread Alex Meade
+1 I thought he was already! which is usually a good sign.

On Thu, May 5, 2016 at 1:39 PM, Mike Perez  wrote:

> On 13:16 May 03, Sean McGinnis wrote:
> > Hey everyone,
> >
> > I would like to nominate Michał Dulko to the Cinder core team. Michał's
> > contributions with both code reviews [0] and code contributions [1] have
> > been significant for some time now.
>
> +1 welcome!
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova] Austin summit priorities session recap

2016-05-05 Thread Matt Riedemann
There are still a few design summit sessions from the summit that I'll 
recap but I wanted to get the priorities session recap out as early as 
possible. We held that session in the last slot on Thursday. The full 
etherpad is here [1].


The first part of the session was mostly going over schedule milestones.

We already started Newton with a freeze on spec approvals for new things 
since we already have a sizable backlog [2]. Now that we're past the 
summit we can approve specs for new things again.


The full Newton release schedule for Nova is in this wiki [3].

These are the major dates from here on out:

* June 2: newton-1, non-priority spec approval freeze
* June 30: non-priority feature freeze
* July 15: newton-2
* July 19-21: Nova Midcycle
* Aug 4: priority spec approval freeze
* Sept 2: newton-3, final python-novaclient release, FeatureFreeze, Soft 
StringFreeze

* Sept 16: RC1 and Hard StringFreeze
* Oct 7, 2016: Newton Release

The important thing for most people right now is we have exactly four 
weeks until the non-priority spec approval freeze. We then have about 
one month after that to land all non-priority blueprints.


Keep in mind that we've already got 52 approved blueprints and most of 
those were re-approved from Mitaka, so have been approved for several 
weeks already.


The non-priority blueprint cycle is intentionally restricted in Newton 
because of all of the backlog work we've had spilling over into this 
release. We really need to focus on getting as much of that done as 
possible before taking on more new work.


For the rest of the priorities session we talked about what our actual 
review priorities are for Newton. The list with details and owners is 
already available here [4].


In no particular order, these are the review priorities:

* Cells v2
* Scheduler
* API Improvements
* os-vif integration
* libvirt storage pools (for live migration)
* Get Me a Network
* Glance v2 Integration

We *should* be able to knock out glance v2, get-me-a-network and os-vif 
relatively soon (I'm thinking sometime in June).


Not listed in [4] but something we talked about was volume multi-attach 
with Cinder. We said this was going to be a 'stretch goal' contingent on 
making decent progress on that item by non-priority feature freeze *and* 
we get the above three smaller priority items completed.


Another thing we talked about but isn't going to be a priority is 
NFV-related work. We talked about cleaning up technical debt and 
additional testing for NFV but had no one in the session signed up to 
own that work or with concrete proposals on how to make improvements in 
that area. Since we can't assign review priorities to something that 
nebulous it was left out. Having said that, Moshe Levi has volunteered 
to restart and lead the SR-IOV/PCI bi-weekly meeting [5] (thanks again, 
Moshe!). So if you (or your employer, or your vendor) are interested in 
working on NFV in Nova please attend that meeting and get involved in 
helping out that subteam.


[1] https://etherpad.openstack.org/p/newton-nova-summit-priorities
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html

[3] https://wiki.openstack.org/wiki/Nova/Newton_Release_Schedule
[4] 
https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html
[5] 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093541.html


--

Thanks,

Matt Riedemann


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


[openstack-dev] [Cloudlet] Need help in creating RST file for specs

2016-05-05 Thread prakash RAMCHANDRAN

Hi all,
Bit rusty returning after Havana to OpenStack for Dev issues.
Goal : Need help in creating a new proposal for Cloudlet...Any takers please 
respond.

Am sure with knowledgeable folks like we have in OpenStack dev,  all I need to 
say is this like a Data Center at the Edge in a VM or Container on a Host or 
cluster (Host aggregation). So few things already exit on OpenStack Liberty, 
but need the Network Based management of Cloudlet with hand-off between edges 
(not exactly a live migration) but a kind of Base + Delta (Image of disk +mem), 
so obviously lies between Nova compute and Neutron Network which is the real 
pain point. Once we have functional piece covered via API and API engine, we 
will deal with low latency, throughput and all those cool stuff.
My limitations are getting back to basics to be able to surmount the CI/CD 
pipeline of the Project creation and once basic project is created will help 
get Cloudlet to be a major initiative for OpenStack.
Those who can build we have a long journey and will need your consistent 
support.
So finally we all will see this is worth the efforts to move the mountains to 
get Cloud to an intermediary Cloudlet.

Here is two years of history if you really need background.
But all we need for now is a Project created as Cloudlet with specs borrowed 
from history below and start the 4O's of OpenStack to bring it next wave 
besides OPNFV.
ThanksPrakash


 Fresh from 
OpenStack Austin Summit trying to launch 
Cloudlet--
---


Including the current Nova PTL, Matt Riedemann.
These topics are probably best discussed on the openstack-dev mailing list.
Have you submitted a spec for this yet, as requested on the blueprint?For more 
details please see:
http://docs.openstack.org/developer/nova/how_to_get_involved.html
http://docs.openstack.org/developer/nova/process.html#how-do-i-get-my-code-merged

The nova unconference sessions at the summit are designed to give people a 
chance to raise topics like this one, and get quick feedback on them, as 
described in the summit schedule. That works best if you have already submitted 
your spec.
Please note we are in the process of removing all the Nova API extension 
points. They have been deprecated for a few cycles now.

I think my previous response on this topic was that I consider this out of 
scope for Nova:http://docs.openstack.org/developer/nova/project_scope.html
And honestly it feels like something that would be better done on top of 
magnum, or something like magnum.
Many thanks,
John
PSParticular company affiliation is not important here.But diverse affiliation 
within a group is very helpful when forming these sorts of ideas.
On 5 May 2016 at 02:53, Prakash Ramchandran  
wrote:
John and Armando, I have a project called "cloudlet" which has two parts one 
for extending Nova API and that also deals with low latency handoff at the 
edge.Been struggling to get it accepted either in Nova or Neutron and tried 
reaching through Telco as well Product Working Groups. All ends up in PTLs to 
decide if this is good use case to allow for creating of a new project. Here is 
the first attempt in Liberty with a Blueprint in 
Nova.https://blueprints.launchpad.net/nova/+spec/cloudlet Next I attempted 
through Telco/OPNFV channel that lead to following use case approval scenario. 
Now with two summits gone I am still not ready with a project to work in Open 
with 4'Os under Project creation requirements for OpenStack. Is it possible for 
any PTL Nova or Neutron to recommend this using exiting Blueprint and assign it 
to a new project called cloudlet? I spoke to Jermy Stanley in infrastructure 
team and he gave links to 
Openstack-Project-team-guidehttp://docs.openstack.org/project-team-guide I 
tried follow it but with so many items like Zuul, Gerrit, name space, I find it 
difficult to cover  all aspects to reach a simple project creation.Is it 
possible to convert the Blueprint in nova as above with specs for Cloudlet and 
give me an name space "cloudlet" to start organizing a separate project. Any 
help from you all will help, and my OpenStack userid is connected with 
pramc...@yahoo.com and am ccing myself. Not expecting any miracles but a simple 
help from any one of you can at least get me on the road to new project 
creation.If you want to add a committer from HP or Intel or rackspace I will 
certainly work with them to get all RST files etc if that helps. ThanksPrakash__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [tricircle] About the dynamic pod binding

2016-05-05 Thread Shinobu Kinjo
Hi Yipei,

On Thu, May 5, 2016 at 9:54 PM, Yipei Niu  wrote:
> Hi, all,
>
> For dynamic pod binding, I have some questions.
>
[snip]
> 3. How is Tricircle aware of what type of resource wanted by tenants? For
> example, a tenant wants to boot VMs for CAD modelling with corresponding
> flavor. But in current code, the flavorRef is not get involved in function
> get_pod_by_az_tenant, when querying pod bindings. So do we need to modify
> the pod binding table to add such a column?

Working through code bases, probably you are talking about future
implementation, I guess.

Cheers,
Shinobu

>
> Best regards,
> Yipei



-- 
Email:
shin...@linux.com
shin...@redhat.com

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


Re: [openstack-dev] [Keystone][Nova] Any Code Examples of Other Services Using Keystone Policy?

2016-05-05 Thread Adam Young

On 05/05/2016 05:54 PM, Dolph Mathews wrote:
My understanding from the summit session was that we should have a 
specific role defined in keystone's policy.json here:


https://github.com/openstack/keystone/blob/a16287af5b7761c8453b2a8e278d78652497377c/etc/policy.json#L37

Which grants access to nothing in keystone beyond that check. So, the 
new rule could be revised to something as generic as:


  "identity:get_project": "rule:admin_required or 
project_id:%(target.project.id )s or 
role:identity_get_project",


Where the new role name I appended at the end exactly matches the 
policy rule name.
Would we expect the have the implied rule that Member implies 
identity_get_project?





However, unlike the summit discussion, which specified only providing 
access to HEAD /v3/projects/{project_id}, keystone's usage of policy 
unfortunately wraps both HEAD and GET with the same policy check.


On Thu, May 5, 2016 at 3:05 PM Augustina Ragwitz 
> wrote:


I'm currently working on the spec for Project ID Validation in Nova
using Keystone. The outcome of the Design Summit Session was that the
Nova service user would use the Keystone policy to establish
whether the
requester had access to the project at all to verify the id. I was
wondering if there were any code examples of a non-Keystone service
using the Keystone policy in this way?

Also if I misunderstood something, please feel free to correct me
or to
clarify!

Here is the etherpad from the session:
https://etherpad.openstack.org/p/newton-nova-keystone
And here is the current spec: https://review.openstack.org/#/c/294337


--
Augustina Ragwitz
Sr Systems Software Engineer, HPE Cloud
Hewlett Packard Enterprise
---
irc: auggy

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

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

--
-Dolph


__
OpenStack Development Mailing List (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] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Tony Breeds
On Thu, May 05, 2016 at 02:35:46PM -0400, Doug Hellmann wrote:

> This has been a lively thread, and the summit session was similarly
> animated. I'm glad to see so much interest in managing our dependencies!
> 
> As we discussed at the summit, my primary objective with dependency
> management this cycle is actually to spin it out into its own team, like
> we did with stable management over the last year. We discussed several
> things that team might undertake, including reviewing all of our
> existing dependencies to ensure they are all still actually needed;
> reviewing any overlap between dependencies to try to remove items from
> the list; and implementing some of the other changes we discussed such
> as allowing overlapping ranges between the global and per-project lists.

I think some of these pro-active things will be key.  A quick check shows we
have nearly 30 items in g-r that don't seem to be used by anything.  So there
is some low hanging fruit there.  Search for overlapping requirements and then
working with the impacted teams is a big job but again a very worthwhile goal.

> We had no volunteers to serve as PTL of that new team,

I was only have joking when I said I can learn how to be a PTL in 2 things at
the same time :)

Regardless lets try to grow a team from the volunteers then we can decide what
the spin off looks like.

Yours Tony.


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] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Tony Breeds
On Thu, May 05, 2016 at 04:18:08PM -0400, Davanum Srinivas wrote:
> prometheanfire,
> 
> I'll get the ball rolling next week. i.e, schedule a meeting, get
> started on writing down what we do usually for vetting requirements
> changes etc.

Please try to set this for a time that isn't terrible for Eastern Australia
(UTC+1000 ATM)

I'm keen to be involved in the meetings.

Yours Tony.


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] [nova][live migration] Request to merge initial storage pool patches

2016-05-05 Thread Michael Still
On Fri, May 6, 2016 at 12:50 AM, Matthew Booth  wrote:

> I mentioned in the meeting last Tuesday that there are now 2 of us working
> on the persistent storage metadata patches: myself and Diana Clarke. I've
> also been talking to Paul Carlton today trying to work out how he can get
> moving with the subsequent libvirt storage pools work without a huge amount
> of conflict. We're going to work that out, but something which would help
> us enormously while we work together is to knock off some semi-dependent
> patches at the beginning of the series.
>
> Specifically there are 5 patches which precede the series. None of these 5
> patches are really part of the series, but the series depends on all 5 to a
> greater or lesser degree. In order, they are:
>
> Only attempt to inject files if the injection disk exists
> https://review.openstack.org/#/c/250872/
>
> Remove fake_imagebackend.Raw and cleanup dependent tests
> https://review.openstack.org/#/c/267661/
>
> Rename Image.check_image_exists to Image.exists()
> https://review.openstack.org/#/c/270998/
>
> Rename Raw backend to NoBacking
> https://review.openstack.org/#/c/279626/
>
> Remove deprecated option libvirt.remove_unused_kernels
> https://review.openstack.org/#/c/265886/
>
> These have all been reviewed previously and attracted +1s. I just rebased
> them, so they may have been lost, but I'm pretty sure they're ready for
> prime time. These patches aren't really what the series is about, but they
> are currently the principal source of merge conflicts. If we could get
> these out of the way it would make it much easier for the 3 of us working
> on the substantive series. Any chance of some core reviewer attention to
> get these moving?
>
> As for the status of the rest of the series, there are 2 more which I
> don't expect to change:
>
> Add a lock() context manager to image backend
> https://review.openstack.org/#/c/279625/
>
> Introduce ImageCacheLocalPool
> https://review.openstack.org/#/c/279669/
>
> Please review these too. However, these patches aren't ready to be merged
> because they don't add users of the interfaces they introduce.
>
> Everything after that is definitely changing. Diana and I are currently
> working on cranking through these backend by backend. I'll provide a weekly
> progress update in the live migration meeting.
>
> TL;DR Core reviewers: please review the first 5 patches listed above.
> There will be cake.
>

I'm very open to bribes. How will this cake be delivered?

Michael

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


Re: [openstack-dev] [neutron][FWaaS] __init__ arguments issue status

2016-05-05 Thread Doug Hellmann
Excerpts from Nate Johnston's message of 2016-05-05 17:40:13 -0400:
> FWaaS team,
> 
> After a day of looking at the tests currently failing in the FWaaS repo, I
> believe I have the issue narrowed down considerably. First, to restate what
> is going on.  If you check out the neutron-fwaas repository and run `tox -e
> py27` in it, you will get six errors all in the
> neutron_fwaas.tests.unit.services.firewall.agents.varmour.test_varmour_router.TestVarmourRouter
> section.
> Running the py34 tests results in similar problems.  The failures follow
> the following form:
> 
> Captured traceback:
> 
> ~~~
> 
> Traceback (most recent call last):
> 
>   File
> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
> line 190, in test_agent_external_gateway
> 
> router = self._create_router()
> 
>   File
> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
> line 87, in _create_router
> 
> router = varmour_router.vArmourL3NATAgent(HOSTNAME, self.conf)
> 
>   File
> "neutron_fwaas/services/firewall/agents/varmour/varmour_router.py", line
> 54, in __init__
> 
> super(vArmourL3NATAgent, self).__init__(host, conf)
> 
>   File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/agent.py",
> line 244, in __init__
> 
> super(L3NATAgent, self).__init__(host=self.conf.host)
> 
>   File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/ha.py",
> line 93, in __init__
> 
> super(AgentMixin, self).__init__(host)
> 
>   File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/dvr.py",
> line 30, in __init__
> 
> super(AgentMixin, self).__init__(host)
> 
>   File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/agent.py",
> line 70, in __init__
> 
> super(FWaaSAgentRpcCallbackMixin, self).__init__(host)
> 
>   File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/manager.py",
> line 44, in __init__
> 
> super(Manager, self).__init__(conf)
> 
>   File "/home/njohns002/
> github.com/openstack/neutron-fwaas-311159/.tox/py27/lib/python2.7/site-packages/oslo_service/periodic_task.py",
> line 177, in __init__
> 
> super(PeriodicTasks, self).__init__()
> 
> TypeError: __init__() takes exactly 2 arguments (1 given)
> 
> I pinged the Oslo folks, and they were able to help me look into the issue,
> which cleared oslo.service of any role.  The change that introduced this is
> actually a neutron change - https://review.openstack.org/#/c/223343/ - and
> I could experimentally test for it by doing the following, which checks out
> the change before the problem one, "Remove BGP code from neutron".  At that
> point `tox -e py27` could complete successfully.
> 
> Everything works with the older commit:   cd .tox/py27/src/neutron && git
> checkout fe702f8f2af265554c7ff6f464b99562f8c54254 && cd - && tox -e py27
> Things break with commit 223343:  cd .tox/py27/src/neutron && git
> checkout f31861843d90e013d31fb76fc576b49a35e218aa4  && cd - && tox -e py27
> 
> My guess on this is that the reason for the breakage is due to multiple
> inheritance and the changing of the ancestry for the L3NATAgent object.  So
> the focus of my effort (with Margaret Frances providing crucial insight) is
> determining what precisely needs to be fixed or reverted to make this work,
> while in keeping with the removal of FWaaS code from Neutron.  I shall
> continue to look at this tomorrow, but if anyone wishes to pick up the
> torch and figure this out then you should feel free to do so.  If not, I
> shall resume tomorrow.
> 
> Thanks,
> 
> --N.

Based on looking at the class hierarchy for vArmourL3NATAgent, I think
the problem is that the mixin classes up and down that hierarchy don't
take the same arguments for __init__(). That's going to make using super()
difficult. Normally one would just need to switch the order of the base
classes so all of the mixins are initialized before the Manager and
PeriodicTask base classes, but doing that doesn't fix the problem in
this case.

Is it possible to make all of the mixin APIs the same?

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] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

2016-05-05 Thread Cathy Zhang
Hi everyone,

We had a discussion on the two topics during the summit. Here is the etherpad 
link for the discussion. 
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit

We agreed to continue the discussion on Neutron channel on a weekly basis. It 
seems UTC 1700 ~ UTC 1800 Tuesday is good for most people. 
Another option is UTC 1700 ~ UTC 1800 Friday. 

I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
this time is good for all people who have interest and like to contribute to 
this work. We plan to start the first meeting on May 17. 

Thanks,
Cathy


-Original Message-
From: Cathy Zhang 
Sent: Thursday, April 21, 2016 11:43 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; 
Shaughnessy, David; Eichberger, German; Henry Fourie; arma...@gmail.com; Miguel 
Angel Ajo; Reedip; Thierry Carrez
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics. 
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference. 

Thanks,
Cathy


-Original Message-
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Cathy Zhang  wrote:

> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following 
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in 
> networking-sfc project and QoS also has a FC. It makes sense that we 
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
> service etc.
> features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to the feature.

Anyway, I agree that classifier API belongs 

Re: [openstack-dev] cross-OpenStack L2 Networking spec review

2016-05-05 Thread Shinobu Kinjo
Hi Joe,

Thank you for your message.
I've CCed dev list since we are still seeking more awesome
contributors to accelerate and improve this project.
And I believe that this topic you wrote up in your previous message is
one of interesting topics.

Cheers,
Shinobu

On Thu, May 5, 2016 at 6:29 PM, joehuang  wrote:
> Hello,
>
> As discussed with Xiongqiu and Ronghui, the spec will be written co-author 
> with Zhiyuan and I. So please review the spec after new patch updated.
>
> And for Feng Pan, he has deep knowledge in OpenStack and networking, and we 
> met in Austin OpenStack summit, he is pleased to join the review.
>
> For Pan has not attended the initial cross OpenStack L2 networking 
> discussion, the etherpad will be good to learn the background: 
> https://etherpad.openstack.org/p/TricircleCrossPodL2Networking
>
> And this slides will help to learn Tricircle quickly: 
> https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit
>
> Best Regards
> Chaoyi Huang ( Joe Huang )
>
>
> -Original Message-
> From: XiongQiu Long (Code Review) [mailto:rev...@openstack.org]
> Sent: Wednesday, May 04, 2016 9:08 PM
> To: Zhiyuan Cai; Shinobu KINJO; Liuhaixia; joehuang; lige; Ronghui Cao
> Cc: Shinobu Kinjo; Khayam Gondal; tangzhuo; Yipei Niu; shiyangkai
> Subject: Change in openstack/tricircle[master]: Add cross-pod L2 Networking 
> spec file
>
> Hello Zhiyuan Cai, Shinobu KINJO, Jenkins, liuhaixia, Chaoyi Huang, lige, 
> Ronghui Cao,
>
> I'd like you to reexamine a change.  Please visit
>
> https://review.openstack.org/304540
>
> to look at the new patch set (#4).
>
> Change subject: Add cross-pod L2 Networking spec file 
> ..
>
> Add cross-pod L2 Networking spec file
>
> Change-Id: I616048c13d03f48aa16d9ff48572b0d5a49d6fb4
> ---
> A specs/cross-pod-l2-networking.rst
> 1 file changed, 263 insertions(+), 0 deletions(-)
>
>
>   git pull ssh://review.openstack.org:29418/openstack/tricircle 
> refs/changes/40/304540/4
> --
> To view, visit https://review.openstack.org/304540
> To unsubscribe, visit https://review.openstack.org/settings
>
> Gerrit-MessageType: newpatchset
> Gerrit-Change-Id: I616048c13d03f48aa16d9ff48572b0d5a49d6fb4
> Gerrit-PatchSet: 4
> Gerrit-Project: openstack/tricircle
> Gerrit-Branch: master
> Gerrit-Owner: XiongQiu Long 
> Gerrit-Reviewer: Chaoyi Huang 
> Gerrit-Reviewer: Jenkins
> Gerrit-Reviewer: Khayam Gondal 
> Gerrit-Reviewer: Ronghui Cao 
> Gerrit-Reviewer: Shinobu KINJO 
> Gerrit-Reviewer: Shinobu Kinjo 
> Gerrit-Reviewer: XiongQiu Long 
> Gerrit-Reviewer: Yipei Niu 
> Gerrit-Reviewer: Zhiyuan Cai 
> Gerrit-Reviewer: lige 
> Gerrit-Reviewer: liuhaixia 
> Gerrit-Reviewer: shiyangkai 
> Gerrit-Reviewer: tangzhuo 



-- 
Email:
shin...@linux.com
shin...@redhat.com

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


Re: [openstack-dev] Requirements for becoming approved official project

2016-05-05 Thread Shinobu Kinjo
Thank you for suggestions.
At this stage, we are just trying to become an official project.

Cheers,
S

On Fri, May 6, 2016 at 2:50 AM, Doug Hellmann  wrote:
> Excerpts from Mike Perez's message of 2016-05-05 09:59:58 -0700:
>> On 14:40 Apr 30, Shinobu Kinjo wrote:
>> > Hi Tom,
>> >
>> > First sorry for bothering you -;
>> >
>> > We are trying to make the tricircle project [1] one of the opnestack
>> > official projects. And we are referring to project team guide to make
>> > sure what are requirements. [2]. Reading this guide, what we need to
>> > consider right now is open development, I think (but not 100% sure).
>> > [3]
>>
>> I think you're looking for:
>>
>> http://governance.openstack.org/reference/tags/tc-approved-release.html
>>
>
> That list is only for projects seeking to be included in DefCore.
> Nothing as new as tricircle is likely to qualify for that status, so I
> wouldn't worry too much about it, for now.
>
> If tricircle just wants to be an official project, the starting place is
> http://governance.openstack.org/reference/new-projects-requirements.html
>
> 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



-- 
Email:
shin...@linux.com
shin...@redhat.com

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


Re: [openstack-dev] [Keystone][Nova] Any Code Examples of Other Services Using Keystone Policy?

2016-05-05 Thread Dan Smith
> I'm currently working on the spec for Project ID Validation in Nova
> using Keystone. The outcome of the Design Summit Session was that the
> Nova service user would use the Keystone policy to establish whether the
> requester had access to the project at all to verify the id. I was
> wondering if there were any code examples of a non-Keystone service
> using the Keystone policy in this way?
> 
> Also if I misunderstood something, please feel free to correct me or to
> clarify!

Just to clarify, the outcome as I understood it is:

/Instead/ of a Nova service user, Nova should use the credentials of the
user doing the quota manipulation to authenticate a request to keystone
to check for the presence of the target user. That means doing a HEAD or
GET on the tenant in keystone using the credentials provided to Nova for
the quota operation. The only Keystone policy involved is making sure
that the user has permission to do that HEAD or GET operation (which is
really just a deployment thing).

--Dan

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


Re: [openstack-dev] [Keystone][Nova] Any Code Examples of Other Services Using Keystone Policy?

2016-05-05 Thread Dolph Mathews
My understanding from the summit session was that we should have a specific
role defined in keystone's policy.json here:


https://github.com/openstack/keystone/blob/a16287af5b7761c8453b2a8e278d78652497377c/etc/policy.json#L37

Which grants access to nothing in keystone beyond that check. So, the new
rule could be revised to something as generic as:

  "identity:get_project": "rule:admin_required or project_id:%(
target.project.id)s or role:identity_get_project",

Where the new role name I appended at the end exactly matches the policy
rule name.

However, unlike the summit discussion, which specified only providing
access to HEAD /v3/projects/{project_id}, keystone's usage of policy
unfortunately wraps both HEAD and GET with the same policy check.

On Thu, May 5, 2016 at 3:05 PM Augustina Ragwitz 
wrote:

> I'm currently working on the spec for Project ID Validation in Nova
> using Keystone. The outcome of the Design Summit Session was that the
> Nova service user would use the Keystone policy to establish whether the
> requester had access to the project at all to verify the id. I was
> wondering if there were any code examples of a non-Keystone service
> using the Keystone policy in this way?
>
> Also if I misunderstood something, please feel free to correct me or to
> clarify!
>
> Here is the etherpad from the session:
> https://etherpad.openstack.org/p/newton-nova-keystone
> And here is the current spec: https://review.openstack.org/#/c/294337
>
>
> --
> Augustina Ragwitz
> Sr Systems Software Engineer, HPE Cloud
> Hewlett Packard Enterprise
> ---
> irc: auggy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
-Dolph
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Doug Hellmann
Excerpts from Ian Cordasco's message of 2016-05-05 16:10:09 -0500:
>  
> 
> -Original Message-
> From: Haïkel 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: May 5, 2016 at 15:25:08
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject:  Re: [openstack-dev] [release][requirements][packaging][summit] 
> input needed on summit discussion about global requirements
> 
> > Well, I'm more in favor having it as a sub-team of release mgmt team.
> 
> I have to agree.
> 
> Doug, did you have specific ideas about what a PTL for the requirements team 
> would do? It's not inherently obvious to me what the benefits of having a 
> requirements PTL would be.

The dependencies list was placed under the release team sort of as a
default -- it didn't fit with any project teams, and we knew we would
have to manage freezing the list at certain times in the cycle. I have
full faith that a new standalone team will work with the release team on
that coordination.

Now that we have a lot of projects to manage, the release work takes
a bigger proportion of the release team's time over the entire span
of the cycle.  So it's not so much that a dependency management team
needs to exist in its own right as that the work such a team might do is
being mostly ignored by your current release PTL (me) because of other
priorities, and that's not a good situation for any of us.

Managing the list of dependencies is not quite a full time job, but
it's a focused set of responsibilities that can be carved out from the
current release team duties.  As far as other work, in the short term
there's quite a bit of cleanup to be done of the current dependency
list, and there are a few ongoing projects related to constraints and
other changes to how we manage and use the list that need someone to
drive them. I think having a separate team to own that work will be more
effective than what we have now. Eventually I expect it to settle back
down into a relatively low-level of effort to maintain the list.

Doug

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


Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Doug Hellmann
Excerpts from Davanum Srinivas (dims)'s message of 2016-05-05 16:18:08 -0400:
> prometheanfire,
> 
> I'll get the ball rolling next week. i.e, schedule a meeting, get
> started on writing down what we do usually for vetting requirements
> changes etc.

Thanks, Dims!

Doug

> 
> Thanks,
> Dims
> 
> On Thu, May 5, 2016 at 4:13 PM, Matthew Thode  
> wrote:
> > On 05/05/2016 01:35 PM, Doug Hellmann wrote:
> >> This has been a lively thread, and the summit session was similarly
> >> animated. I'm glad to see so much interest in managing our dependencies!
> >>
> >> As we discussed at the summit, my primary objective with dependency
> >> management this cycle is actually to spin it out into its own team, like
> >> we did with stable management over the last year. We discussed several
> >> things that team might undertake, including reviewing all of our
> >> existing dependencies to ensure they are all still actually needed;
> >> reviewing any overlap between dependencies to try to remove items from
> >> the list; and implementing some of the other changes we discussed such
> >> as allowing overlapping ranges between the global and per-project lists.
> >>
> >> We had no volunteers to serve as PTL of that new team, but we did have
> >> several volunteers offer to help with reviewing requirements changes and
> >> implementation of some of the changes mentioned above. Thanks you! Please
> >> continue with the reviews, and we will take another look at establishing
> >> a separate team somewhere around the middle of the cycle.
> >>
> >> Doug
> >
> > Thanks,
> >
> >   One of the bigger things I think would be good from spinning out a
> > team is to have scheduled meetings on IRC.  Is there a way we can do
> > this without becoming an official project?
> >
> > --
> > Matthew Thode (prometheanfire)
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

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


[openstack-dev] [neutron][FWaaS] __init__ arguments issue status

2016-05-05 Thread Nate Johnston
FWaaS team,

After a day of looking at the tests currently failing in the FWaaS repo, I
believe I have the issue narrowed down considerably. First, to restate what
is going on.  If you check out the neutron-fwaas repository and run `tox -e
py27` in it, you will get six errors all in the
neutron_fwaas.tests.unit.services.firewall.agents.varmour.test_varmour_router.TestVarmourRouter
section.
Running the py34 tests results in similar problems.  The failures follow
the following form:

Captured traceback:

~~~

Traceback (most recent call last):

  File
"neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
line 190, in test_agent_external_gateway

router = self._create_router()

  File
"neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
line 87, in _create_router

router = varmour_router.vArmourL3NATAgent(HOSTNAME, self.conf)

  File
"neutron_fwaas/services/firewall/agents/varmour/varmour_router.py", line
54, in __init__

super(vArmourL3NATAgent, self).__init__(host, conf)

  File "/home/njohns002/
github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/agent.py",
line 244, in __init__

super(L3NATAgent, self).__init__(host=self.conf.host)

  File "/home/njohns002/
github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/ha.py",
line 93, in __init__

super(AgentMixin, self).__init__(host)

  File "/home/njohns002/
github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/dvr.py",
line 30, in __init__

super(AgentMixin, self).__init__(host)

  File "/home/njohns002/
github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/agent/l3/agent.py",
line 70, in __init__

super(FWaaSAgentRpcCallbackMixin, self).__init__(host)

  File "/home/njohns002/
github.com/openstack/neutron-fwaas-311159/.tox/py27/src/neutron/neutron/manager.py",
line 44, in __init__

super(Manager, self).__init__(conf)

  File "/home/njohns002/
github.com/openstack/neutron-fwaas-311159/.tox/py27/lib/python2.7/site-packages/oslo_service/periodic_task.py",
line 177, in __init__

super(PeriodicTasks, self).__init__()

TypeError: __init__() takes exactly 2 arguments (1 given)

I pinged the Oslo folks, and they were able to help me look into the issue,
which cleared oslo.service of any role.  The change that introduced this is
actually a neutron change - https://review.openstack.org/#/c/223343/ - and
I could experimentally test for it by doing the following, which checks out
the change before the problem one, "Remove BGP code from neutron".  At that
point `tox -e py27` could complete successfully.

Everything works with the older commit:   cd .tox/py27/src/neutron && git
checkout fe702f8f2af265554c7ff6f464b99562f8c54254 && cd - && tox -e py27
Things break with commit 223343:  cd .tox/py27/src/neutron && git
checkout f31861843d90e013d31fb76fc576b49a35e218aa4  && cd - && tox -e py27

My guess on this is that the reason for the breakage is due to multiple
inheritance and the changing of the ancestry for the L3NATAgent object.  So
the focus of my effort (with Margaret Frances providing crucial insight) is
determining what precisely needs to be fixed or reverted to make this work,
while in keeping with the removal of FWaaS code from Neutron.  I shall
continue to look at this tomorrow, but if anyone wishes to pick up the
torch and figure this out then you should feel free to do so.  If not, I
shall resume tomorrow.

Thanks,

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


Re: [openstack-dev] [Manila] Any updates on share groups?

2016-05-05 Thread Knight, Clinton
Hi, John.  In the Friday session, the community agreed that groups would 
support multiple share types in the same group, that they would be called 
‘share groups’, and that a higher-level, multi-backend grouping construct to be 
discussed later would be more flexible if based on something like metadata tags 
(allowing shares to have multiple tags).  We haven’t specified the driver 
interface yet, but we’ll aim to keep it similar to the CG interface so driver 
changes should be minimal.

And yes, the community also agreed to adopt a specs process:

* https://review.openstack.org/#/c/311853/
* https://review.openstack.org/#/c/312102/

Clinton




On 5/4/16, 7:16 AM, "John Spray"  wrote:

>Hi all,
>
>Back in the office with only minor jetlag... unfortunately I had to
>skip the discussion last Friday, I was wondering if there was much
>more discussion about how share groups were going to work, especially
>from a driver POV?  The etherpad notes are mainly recap.
>
>I'd like to get ahead of this for the cephfs driver, because we have
>CG support in the existing code.  I'm hoping we'll be able to just
>invisibly map what we used to call CGs into new share groups that
>happen to have the snapshottable group type.
>
>Related: IIRC the group was in favour of adopting a spec process, did
>we agree to do that for the Newton features?
>
>Cheers,
>John
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Ian Cordasco
 

-Original Message-
From: Haïkel 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: May 5, 2016 at 15:25:08
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [release][requirements][packaging][summit] input 
needed on summit discussion about global requirements

> Well, I'm more in favor having it as a sub-team of release mgmt team.

I have to agree.

Doug, did you have specific ideas about what a PTL for the requirements team 
would do? It's not inherently obvious to me what the benefits of having a 
requirements PTL would be.

--  
Ian Cordasco


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


Re: [openstack-dev] [neutron][devstack] State of the refactor

2016-05-05 Thread Armando M.
On 5 May 2016 at 11:31, Sean M. Collins  wrote:

> Sean M. Collins wrote:
> > Here is the patch I'm using to test the refactor against the Neutron
> > CI jobs.
> >
> > https://review.openstack.org/#/c/278417/
> >
>
> Here's the test patch to make sure anything that is using the
> neutron-legacy file isn't disrupted:
>
> https://review.openstack.org/#/c/313049/
>
> Good news everyone! I didn't break neutron-legacy! Hooray!
>

I filed [1], to validate that something else besides Neutron doesn't break
either.

Good job, and kudos to your perseverance...that always pays off in the end
(which is in sight)!

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


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


Re: [openstack-dev] [neutron][devstack] State of the refactor

2016-05-05 Thread Kevin Benton
Where do I propose my new option
NEUTRON_MAYBE_L3_MTU_VXLAN_AGENTMODE_FLOATINGIPS ?

On Thu, May 5, 2016 at 11:31 AM, Sean M. Collins  wrote:

> Sean M. Collins wrote:
> > Here is the patch I'm using to test the refactor against the Neutron
> > CI jobs.
> >
> > https://review.openstack.org/#/c/278417/
> >
>
> Here's the test patch to make sure anything that is using the
> neutron-legacy file isn't disrupted:
>
> https://review.openstack.org/#/c/313049/
>
> Good news everyone! I didn't break neutron-legacy! Hooray!
>
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Fox, Kevin M
Another few related things:

 * We tend to build our images in vm's. so if libguestfs has to spawn in a vm 
nested in that vm, it may have some performance issues. DIB doesn't have that 
problem.
 * We used to build our centos 6 images without grub a while back, but the 
first yum upgrade that upgraded a kernel in them broke things horribly. So grub 
support is very important.
 * Totally untested at this point, but we're going to be supporting uefi based 
VM's soon. We need a tool chain for building those images. I think DIB can 
build them, but last we looked it seems like the code makes some assumptions 
based on what the host is? If so, there is a chicken and an egg issue there?

Thanks,
Kevin

From: Amrith Kumar [amr...@tesora.com]
Sent: Thursday, May 05, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove

Thanks Peter, that is very helpful. I’ve added your comments to the etherpad 
(https://etherpad.openstack.org/p/image-generation-in-openstack)

-amrith

From: Nordquist, Peter L [mailto:peter.nordqu...@pnnl.gov]
Sent: Thursday, May 05, 2016 12:29 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove

Hello all, I’m an Operator that has worked with DIB here for the last few 
months to get some working images for our Private Cloud.  The only major issue 
I could come up with at the summit was the way grub 0.97 is treated in the 
bootloader element.  For Centos 6, I had to find an element that could actually 
install grub 0.97 since when yum goes to update the kernel, it tries to update 
the grub config but not the extlinux config and in our cloud we need the VMs to 
stay updated.  I’m sure the elements I have locally could be useful but the 
current thinking in my organization is to deprecate our Centos 6 use as quickly 
as possible.

I’ve also run into an issue reported here [0] that makes installing a 
bootloader in Centos 6 a pain in either extlinux or grub 0.97.  That’s really a 
quirk of the OS packages I’m using to build the image but still an odd 
situation.  I’ve updated my VMs that build images to the Mitaka RDO release and 
with that release came the qemu-kvm-ev packages so I’m hopeful that these new 
packages might fix this bug.  If not I’ll have to keep using Ubuntu to build my 
Centos 6 images.

Security is a concern for sure but in my environment I have Jenkins spawn a VM 
in the cloud to build these images and I give these VMs enough ram to build the 
image in memory instead of copying the image to disk.

I also have a requirement to standardize our images to using XFS for the root 
partition due to our flavors including a large amount of root disk.  The 
reasoning here is that XFS resizes faster than ext4 so I would have a concern 
if libguestfs could not do this.  It seems like I could just use DIB to fix any 
images that were created from your libguestfs scripts though so it might not be 
that much of a concern.

[0]: https://bugs.launchpad.net/diskimage-builder/+bug/1477179

Peter Nordquist

From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Thursday, May 05, 2016 07:43
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove


[Inactive hide details for Victoria Martínez de la Cruz ---05/05/2016 08:12:33 
AM---Hi all, A few things:]Victoria Martínez de la Cruz ---05/05/2016 08:12:33 
AM---Hi all, A few things:

From: Victoria Martínez de la Cruz 
>
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 05/05/2016 08:12 AM
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove





Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we should 
try to avoid changing tools unless highly necessary. The downsides we found for 
DIB are detailed in this spec [0] and Ethan (in this same thread) also added 
valid points on the Sahara case. My concern here is, should we stick with DIB 
just because is the standard for image creation? Shouldn't we take in 
consideration that some projects, like Sahara, are moving away from?

I think it would be worth trying to see if DIB can address the concerns raised 
by the different projects around image building and improve upon that. By 
improving DIB, I think all these projects and OpenStack in general can benefit 
from it.

- In the long term it would 

Re: [openstack-dev] [tc] License for specs repo

2016-05-05 Thread Ben Swartzlander

On 05/05/2016 04:01 PM, Davanum Srinivas wrote:

Ben,

Have you seen this yet?

http://lists.openstack.org/pipermail/legal-discuss/2014-March/000201.html
https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#Approval_of_the_CCBY_License_for_Documentation.


No I hadn't seen this. It's helpful to know that there is official 
support from the board for using the CCBY license but it's unclear what 
that's supposed to look like, since I can't find a single project that's 
converted their whole specs repo to the new license.


My confusion comes from how to handle the existing Apache 2.0 stuff in 
the cookie cutter. I can't just drop the Apache 2.0 license... The only 
obvious path forward is to create a gross mess like the existing specs 
repos have where there's a mix of the 2 licenses and it's not clear 
which license applies to what.


-Ben



Thanks,
Dims

On Thu, May 5, 2016 at 3:44 PM, Ben Swartzlander  wrote:

On 05/05/2016 03:24 PM, Jeremy Stanley wrote:


On 2016-05-05 12:03:38 -0400 (-0400), Ben Swartzlander wrote:


It appears that many of the existing specs repos contain a
confusing mixture of Apache 2.0 licensed code and Creative Commons
licensed docs.


[...]

Recollection is that the prose was intended to be under CC Attrib.
in line with official documentation, while any sample source code
was intended to be under ASL2 so that it could be directly used in
similarly-licensed software. We likely do a terrible job of
explaining that though, and maybe dual-licensing everything in specs
repos makes more sense? This might also be a better thread to have
on the legal-discuss@ ML.



We may ultimately need to consult legal experts, but I was hoping that we
already had a clear guideline for specs licensing and it was merely being
applied inconsistently. I figured the TC would know if a decision had been
made about this.

I also have a feeling that dual-licensing would be the least-likely-to-fail
option, however I haven't seen examples of how to properly dual-license a
repo in OpenStack so I wasn't going to jump to that option first.

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


Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Haïkel
Well, I'm more in favor having it as a sub-team of release mgmt team.

H,

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


Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Matthew Thode
On 05/05/2016 03:18 PM, Davanum Srinivas wrote:
> prometheanfire,
> 
> I'll get the ball rolling next week. i.e, schedule a meeting, get
> started on writing down what we do usually for vetting requirements
> changes etc.
> 
> Thanks,
> Dims

Thanks, it's nice to have just from a planning perspective.

-- 
-- Matthew Thode (prometheanfire)



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] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Davanum Srinivas
prometheanfire,

I'll get the ball rolling next week. i.e, schedule a meeting, get
started on writing down what we do usually for vetting requirements
changes etc.

Thanks,
Dims

On Thu, May 5, 2016 at 4:13 PM, Matthew Thode  wrote:
> On 05/05/2016 01:35 PM, Doug Hellmann wrote:
>> This has been a lively thread, and the summit session was similarly
>> animated. I'm glad to see so much interest in managing our dependencies!
>>
>> As we discussed at the summit, my primary objective with dependency
>> management this cycle is actually to spin it out into its own team, like
>> we did with stable management over the last year. We discussed several
>> things that team might undertake, including reviewing all of our
>> existing dependencies to ensure they are all still actually needed;
>> reviewing any overlap between dependencies to try to remove items from
>> the list; and implementing some of the other changes we discussed such
>> as allowing overlapping ranges between the global and per-project lists.
>>
>> We had no volunteers to serve as PTL of that new team, but we did have
>> several volunteers offer to help with reviewing requirements changes and
>> implementation of some of the changes mentioned above. Thanks you! Please
>> continue with the reviews, and we will take another look at establishing
>> a separate team somewhere around the middle of the cycle.
>>
>> Doug
>
> Thanks,
>
>   One of the bigger things I think would be good from spinning out a
> team is to have scheduled meetings on IRC.  Is there a way we can do
> this without becoming an official project?
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

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


[openstack-dev] [UX] OpenStack UX core nomination

2016-05-05 Thread Kruithof Jr, Pieter
I would like to nominate Shamail Tahir as a core for the OpenStack UX project.

Shamail has been central to developing a set of personas for the overall 
community and providing his significant expertise with customers.  In some 
ways, he has also been our focal to the other community projects.

His nomination supports the goal of OpenStack UX to support cross-project 
initiatives.

Piet

PTL, OpenStack UX project

Piet Kruithof

Sr User Experience Architect,
Intel Open Source Technology Group

Project Technical Lead (PTL)
OpenStack UX project

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


Re: [openstack-dev] [app-catalog] [glare] [murano] [mistral] Austin summit summary: Community App Catalog

2016-05-05 Thread Christopher Aedo
On Wed, May 4, 2016 at 9:15 PM, Renat Akhmerov  wrote:> Cool, feel free to communicate with us on adding Mistral assets into the> catalog.Of course!  We started a blueprint for the related tasks[1] and hopefully myself or someone from the Mistral team will be able to take a few of the first steps soon.  I think Mistral workflows would be a really useful addition to the Community App Catalog so I'm excited to drive this effort.One of the sessions I saw at the summit really impressed me.  "Using OpenStack to clean up after itself"[2] was really cool to see.  Is that example worflow used during the demo available somewhere?[1]: https://blueprints.launchpad.net/app-catalog/+spec/add-mistral-assets[2]: http://www.openstack.org/videos/video/using-openstack-to-clean-up-after-itself-automatically-run-mistral-workflows-in-response-to-openstack-notifications-Christopher> Renat Akhmerov> @Nokia>> On 05 May 2016, at 06:43, Nikhil Komawar  wrote:>> Thanks Christopher for a really nice summary!>>> On 5/4/16 7:37 PM, Christopher Aedo wrote:>> Hello!  At the summit I was excited to have many conversations with> folks who are already using the Community App Catalog regularly, and> many others who plan to increase their level of participation in the> months to come - I'm really happy to see the continued interest in> this effort.  For those that were unable to join us in Austin, I> wanted to provide a brief summary of what we covered and discussed> during our fishbowl and design sessions.  We tracked everything on an> etherpad[1] which captures the details.>> During the fishbowl session we talked about some of the new things we> implemented in the last cycle including the addition of TOSCA assets> to the catalog and a bunch of new tests that we added to the Horizon> plugin.  We also had an opportunity to discuss our plans to integrate> Glare as a backend for the catalog and everything that will allow us> to do. The most visible bits will be the ability for users to provide> feedback and ratings for assets in addition to subscribing to an asset> so they can be notified when the asset is updated.  We are planning to> complete implementation of the Glare backend within the next four months.>> Following the fishbowl session we had two work sessions during which> we agreed on a few notable things, and the one which will have the> most impact is closer coordination and integration with Murano.  This> will include coordinated efforts on the UI side as well as the OSC> work we've been doing.  The broader intention is to disambiguate the> two projects in order to make it clear the Community App Catalog is> the community run central repository for "things that run on OpenStack> clouds" while still aiming for tight integration where appropriate.>> We will have two cross-project specs coming in the next month to> detail these efforts and make clear our intentions and where things> will overlap.> Thanks again to everyone who was able to attend our sessions, and to> all those who continue to help us build up the Community App Catalog!>> -Christopher> [1]: https://etherpad.openstack.org/p/AUS-app-catalog> __> OpenStack Development Mailing List (not for usage questions)> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>> -->> Thanks,> Nikhil>>> __> OpenStack Development Mailing List (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] [Keystone][Nova] Any Code Examples of Other Services Using Keystone Policy?

2016-05-05 Thread Augustina Ragwitz
I'm currently working on the spec for Project ID Validation in Nova
using Keystone. The outcome of the Design Summit Session was that the
Nova service user would use the Keystone policy to establish whether the
requester had access to the project at all to verify the id. I was
wondering if there were any code examples of a non-Keystone service
using the Keystone policy in this way?

Also if I misunderstood something, please feel free to correct me or to
clarify!

Here is the etherpad from the session:
https://etherpad.openstack.org/p/newton-nova-keystone
And here is the current spec: https://review.openstack.org/#/c/294337


-- 
Augustina Ragwitz
Sr Systems Software Engineer, HPE Cloud
Hewlett Packard Enterprise
---
irc: auggy

__
OpenStack Development Mailing List (not for 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] License for specs repo

2016-05-05 Thread Davanum Srinivas
Ben,

Have you seen this yet?

http://lists.openstack.org/pipermail/legal-discuss/2014-March/000201.html
https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#Approval_of_the_CCBY_License_for_Documentation.

Thanks,
Dims

On Thu, May 5, 2016 at 3:44 PM, Ben Swartzlander  wrote:
> On 05/05/2016 03:24 PM, Jeremy Stanley wrote:
>>
>> On 2016-05-05 12:03:38 -0400 (-0400), Ben Swartzlander wrote:
>>>
>>> It appears that many of the existing specs repos contain a
>>> confusing mixture of Apache 2.0 licensed code and Creative Commons
>>> licensed docs.
>>
>> [...]
>>
>> Recollection is that the prose was intended to be under CC Attrib.
>> in line with official documentation, while any sample source code
>> was intended to be under ASL2 so that it could be directly used in
>> similarly-licensed software. We likely do a terrible job of
>> explaining that though, and maybe dual-licensing everything in specs
>> repos makes more sense? This might also be a better thread to have
>> on the legal-discuss@ ML.
>
>
> We may ultimately need to consult legal experts, but I was hoping that we
> already had a clear guideline for specs licensing and it was merely being
> applied inconsistently. I figured the TC would know if a decision had been
> made about this.
>
> I also have a feeling that dual-licensing would be the least-likely-to-fail
> option, however I haven't seen examples of how to properly dual-license a
> repo in OpenStack so I wasn't going to jump to that option first.
>
> -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



-- 
Davanum Srinivas :: https://twitter.com/dims

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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Amrith Kumar
Thanks Peter, that is very helpful. I’ve added your comments to the etherpad 
(https://etherpad.openstack.org/p/image-generation-in-openstack)

-amrith

From: Nordquist, Peter L [mailto:peter.nordqu...@pnnl.gov]
Sent: Thursday, May 05, 2016 12:29 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove

Hello all, I’m an Operator that has worked with DIB here for the last few 
months to get some working images for our Private Cloud.  The only major issue 
I could come up with at the summit was the way grub 0.97 is treated in the 
bootloader element.  For Centos 6, I had to find an element that could actually 
install grub 0.97 since when yum goes to update the kernel, it tries to update 
the grub config but not the extlinux config and in our cloud we need the VMs to 
stay updated.  I’m sure the elements I have locally could be useful but the 
current thinking in my organization is to deprecate our Centos 6 use as quickly 
as possible.

I’ve also run into an issue reported here [0] that makes installing a 
bootloader in Centos 6 a pain in either extlinux or grub 0.97.  That’s really a 
quirk of the OS packages I’m using to build the image but still an odd 
situation.  I’ve updated my VMs that build images to the Mitaka RDO release and 
with that release came the qemu-kvm-ev packages so I’m hopeful that these new 
packages might fix this bug.  If not I’ll have to keep using Ubuntu to build my 
Centos 6 images.

Security is a concern for sure but in my environment I have Jenkins spawn a VM 
in the cloud to build these images and I give these VMs enough ram to build the 
image in memory instead of copying the image to disk.

I also have a requirement to standardize our images to using XFS for the root 
partition due to our flavors including a large amount of root disk.  The 
reasoning here is that XFS resizes faster than ext4 so I would have a concern 
if libguestfs could not do this.  It seems like I could just use DIB to fix any 
images that were created from your libguestfs scripts though so it might not be 
that much of a concern.

[0]: https://bugs.launchpad.net/diskimage-builder/+bug/1477179

Peter Nordquist

From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Thursday, May 05, 2016 07:43
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove


[Inactive hide details for Victoria Martínez de la Cruz ---05/05/2016 08:12:33 
AM---Hi all, A few things:]Victoria Martínez de la Cruz ---05/05/2016 08:12:33 
AM---Hi all, A few things:

From: Victoria Martínez de la Cruz 
>
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 05/05/2016 08:12 AM
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove





Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we should 
try to avoid changing tools unless highly necessary. The downsides we found for 
DIB are detailed in this spec [0] and Ethan (in this same thread) also added 
valid points on the Sahara case. My concern here is, should we stick with DIB 
just because is the standard for image creation? Shouldn't we take in 
consideration that some projects, like Sahara, are moving away from?

I think it would be worth trying to see if DIB can address the concerns raised 
by the different projects around image building and improve upon that. By 
improving DIB, I think all these projects and OpenStack in general can benefit 
from it.

- In the long term it would be ideal that we reach to a common solution for 
image creation for all the projects that need tailored images: Trove, Sahara, 
Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB for 
image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec is 
up there [0]. I think is his work to kick-off that repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar 
>:
As we discussed at summit, (and consistent with all of the comments) we should 
move ahead with the project to advance the image builder for Trove and make it 
easier to build guest images for Trove by leveraging the DIB elements that we 
have in trove-integration.



To that end, the infra [1] and governance [2] changes have been submitted for 
review. The Launchpad tracker [3] has been registered.



I am working 

Re: [openstack-dev] [tc] License for specs repo

2016-05-05 Thread Ben Swartzlander

On 05/05/2016 03:24 PM, Jeremy Stanley wrote:

On 2016-05-05 12:03:38 -0400 (-0400), Ben Swartzlander wrote:

It appears that many of the existing specs repos contain a
confusing mixture of Apache 2.0 licensed code and Creative Commons
licensed docs.

[...]

Recollection is that the prose was intended to be under CC Attrib.
in line with official documentation, while any sample source code
was intended to be under ASL2 so that it could be directly used in
similarly-licensed software. We likely do a terrible job of
explaining that though, and maybe dual-licensing everything in specs
repos makes more sense? This might also be a better thread to have
on the legal-discuss@ ML.


We may ultimately need to consult legal experts, but I was hoping that 
we already had a clear guideline for specs licensing and it was merely 
being applied inconsistently. I figured the TC would know if a decision 
had been made about this.


I also have a feeling that dual-licensing would be the 
least-likely-to-fail option, however I haven't seen examples of how to 
properly dual-license a repo in OpenStack so I wasn't going to jump to 
that option first.


-Ben Swartzlander


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


Re: [openstack-dev] [tc] License for specs repo

2016-05-05 Thread Jeremy Stanley
On 2016-05-05 12:03:38 -0400 (-0400), Ben Swartzlander wrote:
> It appears that many of the existing specs repos contain a
> confusing mixture of Apache 2.0 licensed code and Creative Commons
> licensed docs.
[...]

Recollection is that the prose was intended to be under CC Attrib.
in line with official documentation, while any sample source code
was intended to be under ASL2 so that it could be directly used in
similarly-licensed software. We likely do a terrible job of
explaining that though, and maybe dual-licensing everything in specs
repos makes more sense? This might also be a better thread to have
on the legal-discuss@ ML.
-- 
Jeremy Stanley

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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Amrith Kumar
Pete, please clarify … I was going to push the dib elements that we currently 
have and you were writing CentOS elements. Is that right?

Seems like there are some crossed wires here.

-amrith

From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com]
Sent: Thursday, May 05, 2016 10:30 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove

We agreed during the summit that we were going to amend the spec to reflect 
latest discussions with regards to having DIB as a primary implementation and 
adding support for libguestfs in parallel. The spec blueprint is named "Trove 
image builder" and it's about building images and not about which tool we are 
going to use. Thanks for creating the artifacts we need to push the code, we 
take it over from there.

2016-05-05 11:12 GMT-03:00 Amrith Kumar 
>:

From: Victoria Martínez de la Cruz 
[mailto:victo...@vmartinezdelacruz.com]
Sent: Thursday, May 05, 2016 9:00 AM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove

Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we should 
try to avoid changing tools unless highly necessary. The downsides we found for 
DIB are detailed in this spec [0] and Ethan (in this same thread) also added 
valid points on the Sahara case. My concern here is, should we stick with DIB 
just because is the standard for image creation? Shouldn't we take in 
consideration that some projects, like Sahara, are moving away from it?
- In the long term it would be ideal that we reach to a common solution for 
image creation for all the projects that need tailored images: Trove, Sahara, 
Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB for 
image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec is 
up there [0]. I think is his work to kick-off that repository.
[amrith] The spec [0] referenced is entitled “Separate trove image build 
project based on libguestfs tools”. I am working on image building using the 
existing DIB elements that are already part of trove-integration. In any event, 
please see line 220 of [0] for a detailed explanation of why I am making the 
repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar 
>:
As we discussed at summit, (and consistent with all of the comments) we should 
move ahead with the project to advance the image builder for Trove and make it 
easier to build guest images for Trove by leveraging the DIB elements that we 
have in trove-integration.

To that end, the infra [1] and governance [2] changes have been submitted for 
review. The Launchpad tracker [3] has been registered.

I am working on taking the existing DIB elements in trove-integration and 
putting them in the new repository (openstack/trove-image-builder). I am also 
going to continue to watch this conversation and record any shortcomings with 
the existing DIB elements in Launchpad [3] and work on fixing those as well. 
Pete mentions one in his earlier email and I’ve logged that in Launchpad [4].

Thanks,

-amrith

[1] https://review.openstack.org/#/c/312805/
[2] https://review.openstack.org/#/c/312806/
[3] https://launchpad.net/trove-image-builder
[4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454



From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Wednesday, May 04, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions) 
>

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove


The way I see this, these are the 2 main concerns I have been hearing regarding 
image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security

I dont think there is any argument regarding the benefits of moving the 
database elements to a seperate repository and packaging and managing them from 
there.

It looks like the case that we make for whether to use libguestfs or DIB for 
image building are in the technical details of how image building happens and 
their nuances - assuming that ease of use & having a simple interface to build 
secure images matters most, I wonder if the end-users would be concerned about 
these details.

By addressing some of the issues like:
- moving the Trove elements to a new repository
- adding 

Re: [openstack-dev] [neutron][devstack] State of the refactor

2016-05-05 Thread Jeremy Stanley
On 2016-05-05 15:57:22 + (+), Sean M. Collins wrote:
[...]
> So we did.
> 
> https://review.openstack.org/168438
[...]

Remind me to buy you and Dean beer the next time I see you. It's
like you flipped the Etch A Sketch upside down and shook vigorously.
<>
-- 
Jeremy Stanley

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


Re: [openstack-dev] [nova][cinder] Austin summit nova/cinder cross-project session recap

2016-05-05 Thread Ildikó Váncsa
Hi All,

First of all thanks Matt for the detailed summary about last week.

As a continuation I would like to add the meeting minutes I captured today on 
the Hangout referred below.

As an overall summary, the most important step for today was to move back a 
little from multi-attach and try to examine the Cinder-Nova interaction before 
moving forward with any kind of addition. Our philosophy here was to simplify 
what we can and move back the responsibilities where they belong.

We started with a quick recap by Scott D'Angelo on what we are trying to solve 
here. The main items were:
* Multi-attach
  * detach issue: when to disconnect volume in Nova/remove target in Cinder
  * too many state checks on Nova side
* Live migration issue
  * calling initialize_connection for the destination host and then for the 
source host again
  * some Cinder drivers export new target, which is an existing issue

John Garbutt asked about the detach case and asked whether 'os-brick' can 
handle the decision when to disconnect a volume. That module would need more 
information in order to be able to make the decision. One of the main concerns 
from Walter Boring was that 'os-brick' is a stateless simple module currently 
and the intention is still to keep it like that.

After this discussion John Griffith described what he is already working on. 
The solution concentrates on 'initialize_connection'. The main changes in the 
plans are to create the attachment at initialize time and also save information 
on Cinder side like the 'host' and 'connector_info'. 'initialize_connection' 
will also be extended with the logic to check whether the attachment already 
exists or not. In the latter case it will not create a new one and will also 
prevent the drivers from the aforementioned extra export. This solution can 
possibly solve the live migration issue as well.

John Griffith will work on the above described solution, that target is to have 
patches up by next week.

The next topic was started by Walter Boring, which is about to remove 
'check_attach' from Nova. Ildiko Vancsa raised the point that 'check_attach' 
looks like a legacy check in Nova, which was not removed when the checks were 
added to 'reserve_volume' to Cinder. As Nova calls 'reserve_volume' after 
'check_attach' the removal of this extra check should be safe. Walter is 
already working on the changes, the patch is targeted for this week. This 
should simplify the interaction between the two modules and keep Cinder as the 
ultimate source of truth.

Walter also started to work on to fix the live migration issue by removing the 
second 'initialize_connection' call from the flow. The patch [1] in WIP state 
is already up for review and needs some review attention to see whether it's 
the best way of solving this issue.

We briefly discussed the hypervisor layer during the meeting as an already 
known step for multi-attach. For libvirt we need to be able to set the 
'shareable' flag for the guest instance in its XML file (to disable caching), 
therefore Nova still needs to know whether a volume is multi-attach enabled or 
not. The volume info already contains this information that Nova can use for 
this check. Because of this reason the other virt drivers will not support 
multi-attach, at least for now, which means an additional check in Nova before 
attaching a multi-attach volume.

We also talked about missing tests. We identified Cinder migrate as a major 
item here. Scott D'Angelo will work on this as Cinder already has a test patch 
up for review for a specific case of this workflow. This test will trigger Nova 
swap volume as well, which is also important in order to be able to safely 
introduce multi-attach. Ildiko Vancsa will work on further test cases in 
Tempest for multi-attach and look into fixing the already existing one that 
Matt Riedemann uploaded during the Mitaka cycle.

Ildiko will also work on the multi-attach spec [2] for Nova and upload a latest 
version adapted to the outcome of the today's meeting for review this week.

Walter brought up the extend volume use case during the meeting. Matt stated 
that this item should be presented and discussed on one of the Nova meetings, 
we did not spend time on this item today.

We also agreed that we will continue with the weekly IRC meetings, which will 
only be the forum to track what we agreed on today and to discuss multi-attach.

Please feel free to add more items or correct me if I'm mistaken on any of the 
above points.

Thanks and Best Regards,
/Ildikó

[1] https://review.openstack.org/#/c/312773/ 
[2] https://review.openstack.org/#/c/304681/ 


> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: May 05, 2016 02:55
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [nova][cinder] Austin summit nova/cinder 
> cross-project session recap
> 
> On Thursday morning the Nova and Cinder teams got together for a
> 

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-05-05 Thread Doug Hellmann
Excerpts from Doug Hellmann's message of 2016-04-17 11:13:15 -0400:
> I am organizing a summit session for the cross-project track to
> (re)consider how we manage our list of global dependencies [1].
> Some of the changes I propose would have a big impact, and so I
> want to ensure everyone doing packaging work for distros is available
> for the discussion. Please review the etherpad [2] and pass the
> information along to colleagues who might be interested.
> 
> Doug
> 
> [1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/9473
> [2] https://etherpad.openstack.org/p/newton-global-requirements
> 

This has been a lively thread, and the summit session was similarly
animated. I'm glad to see so much interest in managing our dependencies!

As we discussed at the summit, my primary objective with dependency
management this cycle is actually to spin it out into its own team, like
we did with stable management over the last year. We discussed several
things that team might undertake, including reviewing all of our
existing dependencies to ensure they are all still actually needed;
reviewing any overlap between dependencies to try to remove items from
the list; and implementing some of the other changes we discussed such
as allowing overlapping ranges between the global and per-project lists.

We had no volunteers to serve as PTL of that new team, but we did have
several volunteers offer to help with reviewing requirements changes and
implementation of some of the changes mentioned above. Thanks you! Please
continue with the reviews, and we will take another look at establishing
a separate team somewhere around the middle of the cycle.

Doug

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


Re: [openstack-dev] [neutron][devstack] State of the refactor

2016-05-05 Thread Sean M. Collins
Sean M. Collins wrote:
> Here is the patch I'm using to test the refactor against the Neutron
> CI jobs.
> 
> https://review.openstack.org/#/c/278417/
> 

Here's the test patch to make sure anything that is using the
neutron-legacy file isn't disrupted:

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

Good news everyone! I didn't break neutron-legacy! Hooray!

-- 
Sean M. Collins

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


Re: [openstack-dev] [neutron][fwaas][vpnaas][lbaas][octavia] summit summary - future of the advanced services

2016-05-05 Thread Sridar Kandaswamy (skandasw)
Hi All:

Doug, thanks for the update and agree. On fwaas - we have some new
contributors who are enthusiastic to make things happen in N. But if
contributor priorities change and we struggle - will reach out to expedite
the removal.

Thanks

Sridar

On 5/5/16, 9:56 AM, "Doug Wiegley"  wrote:

>Egads, that¹s a long subject prefix.  Anyways, we had a design session on
>the future of the advanced services:
>
>https://etherpad.openstack.org/p/newton-neutron-future-adv-services
>
>In a nutshell, vpn and fw are critically lacking active contributors at
>present. Again. A proposal was made to remove them from the neutron
>stadium, effectively making them the equivalent of stackforge projects
>(openstack experimental in the new terminology.)  This was rejected in
>favor of giving them until Ocata-1 to retain stadium status, similar to
>the criteria laid out in the later neutron stadium discussion:
>
>https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolutio
>n
>
>Given how often we¹ve extended the lives of those two repos by yet
>another six months, this time we¹ll be looking for regular progress up to
>ocata-1, with final criteria being done (ish) by then. But, as agreed at
>the summit, if things go utterly dark post-summit, then you can expect to
>see governance patches to remove them from the stadium much faster than
>Ocata-1.
>
>After that session, but worth mentioning here, further discussions led to
>a proposal to make lbaas a standalone project, with a standalone
>endpoint, but adopting the current API:
>
>https://review.openstack.org/#/c/310805/
>https://review.openstack.org/#/c/310667/
>
>and here¹s a WIP governance patch for flavor:
>
>https://review.openstack.org/313056
>
>This achieved broad consensus among those present for the follow-up
>conversations (-1 nits on that patch aside), but please comment on any of
>those if you have comments/concerns.
>
>Next steps:
>
>- Monitor progress of vpn and fw.
>- Cleanup lbaas spinout specs, generate a timeline for minimum work
>required.
>
>Thanks,
>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] [tc] Swift api compat. Was: supporting Go

2016-05-05 Thread Fox, Kevin M
I strongly disagree.

Would we be happy if we stripped out all of the code out of nova for non kvm 
and said, "if you want vmware or xen, support you have to reimplement nova from 
scratch in an api compatible way out of tree"? "And on top of that, we won't 
ever test compatibility for anything not nova-kvm, its not openstack"?

What about cinder? "We only support iscsi, if you want a cinder api that speaks 
to ceph, you need to reimplement all the cinder api yourself out of tree, and 
we won't support any tests"?

Trove, you can deploy any db you want so long as its mysql... sahara, anything 
so long as its vanilla hadoop etc.

Of course not. Why is Swift special here? There's a reason those other 
openstack projects provide flavors. Because no single backend has proven to 
work for 100% of the users use cases.

The same need has shown up for Swift. The protocol is great. The 
implementation, while also great for a lot of folks/use cases (truely.), it 
doesn't work for all use cases an op has. An op has to make an exclusive choice 
today, and its hard on ops and other vendors. Why is this situation acceptable 
for Swift and not other openstack projects?

As an Op, I have personally seen 2 impediments:
1. We currently run the radosgw. Other vendors support stuff like swift api 
backed to tape. we are interested in it but cant since there can be only one 
thing and the radosgw case is currently more important. This leaves us to 
choose between the least bad of the partial solutions, not a complete one.

2. Incompatibilities in api. This has shown up, for example, in Trove not being 
able to backup to a radosgw.

I believe most the reason for this is lack of testing, and thats been hung up 
on:
 1. circular logic around, the swift software defines the swift api. We don't 
have to standardize it since its in tree and nothing else can be swift.
 2. we don't have to support tests for anything but "swift". since the swift 
software is the api reference by definition above, there is little point in 
testing much other then, is swift enabled or not. If its not the swift 
software, it couldn't possibly be the swift api and we shouldn't test 
compatibility. I think this is a horrible thing.
 
Operators have indeed seen issues with it. Saying its been "successful" is 
incorrect. Its been mostly good enough sort of with a bunch of issues that have 
plagued us.

Thanks,
Kevin

From: Pete Zaitcev [zait...@redhat.com]
Sent: Thursday, May 05, 2016 9:38 AM
To: Fox, Kevin M
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go

On Wed, 4 May 2016 21:52:49 +
"Fox, Kevin M"  wrote:

> Swift is in a strange place where the api is implemented in a way to
> favor one particular vendor backend implementation.

Sorry, but I disagree with the above assessement. There is no one
particular vendor like that, because the only vendor of Swift source
is OpenStack, and vendors of pre-packaged Swift are legion, all equal:
Red Hat, HPe (Helion), SwiftStack, Mirantis, and more.

> I'd love to be able to plugin Swift into our sites, but because we
> can only have one, the various tradoffs have lead us to deploy RadosGW
> most of the time.

The fact that you succeeded in running OpenStack with RadosGW proves that
there is no issue here that impedes a development or use of OpenStack.
We at Red Hat will be happy to support an installation of OpenStack using
Ceph underpinning it as integrated storage solution. Or, an installation
that uses the OpenStack-released, reference implementation of Swift,
which we integrate too. We're flexible like that, according to the needs
of each customer.

-- Pete


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


[openstack-dev] [kolla] Ironic broken on Ubuntu

2016-05-05 Thread Franck Barillaud
Hi, 

Trying to setup an Ironic environment on Ubuntu. 

CONTAINER IDIMAGECOMMAND CREATED   STATUS  
 PORTSNAMES
0838b01dcd34 
192.168.32.203:4000/kollaglue/ubuntu-source-ironic-inspector:2.0.0  
"kolla_start"25 minutes ago  Restarting (127) 12 minutes 
agoironic_inspector
b973c27bcf5f 
192.168.32.203:4000/kollaglue/ubuntu-source-ironic-conductor:2.0.0  
"kolla_start"25 minutes ago  Up 25 minutes   
ironic_conductor
8573dba2b21e 192.168.32.203:4000/kollaglue/ubuntu-source-ironic-api:2.0.0  
   "kolla_start"25 minutes ago  Up 25 minutes  
   ironic_api
446745b8e8ba 192.168.32.203:4000/kollaglue/ubuntu-source-ironic-pxe:2.0.0  
   "kolla_start"26 minutes ago  Up 25 minutes  
   ironic_pxe
64d1b576911f 
192.168.32.203:4000/kollaglue/ubuntu-source-nova-compute-ironic:2.0.0  
"kolla_start"27 minutes ago  Restarting (1) 12 minutes ago 
 nova_compute_ironic
050d333a4dc9 192.168.32.203:4000/kollaglue/ubuntu-source-horizon:2.0.0 
  "kolla_start"About an hour ago   Up About an hour
   horizon

All the containers are started expect for 'ironic_inspector' and 
'nova_compute_ironic'.  Looking at the 
'kolla/docker/ironic/ironic-inspector' shows no contruct for Ubuntu.

FROM {{ namespace }}/{{ image_prefix }}ironic-base:{{ tag }}
MAINTAINER {{ maintainer }}

{% if install_type == 'binary' %}
{% if base_distro in ['centos', 'fedora', 'oraclelinux', 'rhel'] %}

RUN yum -y install \
openstack-ironic-inspector \
&& yum clean all

{% endif %}
{% endif %}

{{ include_footer }}

USER ironic

Rebuilt successufully the ironic containers on centos. The question is how 
can I deploy them ? Using 'kolla-ansible deploy' does not support 'mixed' 
environments. 

Regards,
Franck Barillaud
Cloud Architect
Master Inventor
Ext Phone: (512) 286-5242Tie Line: 363-5242
e-mail: fbari...@us.ibm.com


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


Re: [openstack-dev] Requirements for becoming approved official project

2016-05-05 Thread Doug Hellmann
Excerpts from Mike Perez's message of 2016-05-05 09:59:58 -0700:
> On 14:40 Apr 30, Shinobu Kinjo wrote:
> > Hi Tom,
> > 
> > First sorry for bothering you -;
> > 
> > We are trying to make the tricircle project [1] one of the opnestack
> > official projects. And we are referring to project team guide to make
> > sure what are requirements. [2]. Reading this guide, what we need to
> > consider right now is open development, I think (but not 100% sure).
> > [3]
> 
> I think you're looking for:
> 
> http://governance.openstack.org/reference/tags/tc-approved-release.html
> 

That list is only for projects seeking to be included in DefCore.
Nothing as new as tricircle is likely to qualify for that status, so I
wouldn't worry too much about it, for now.

If tricircle just wants to be an official project, the starting place is
http://governance.openstack.org/reference/new-projects-requirements.html

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] [release] Release countdown for week R-21, May 9-13

2016-05-05 Thread Doug Hellmann
Welcome back from summit!

As we did last cycle, the release team will be sending reminder emails
as we count down toward the Newton release. If all goes as planned,
these emails will be sent just before the week mentioned in the subject
(on my Thursday, but some of you live in the future).

Release liaisons, PTLs, and other interested parties should read
these emails to be aware of process notes, especially as we get close
to significant dates on the schedule. I'll try to keep them brief, but
email is still the best way we have of communicating and that only works
if you actually read them. "I did not see your email" is not going to
be accepted as a reason to slip a deadline this cycle.

Focus
-

Teams should be focusing on wrapping up incomplete work left over from
the end of the Mitaka cycle, finalizing and announcing plans from the
summit, and completing specs and blueprints.

General Notes
-

As previously mentioned, due to a couple of different issues we have a
release hiaitus in place until 9 May. I'll make a separate announcement
when that is resolved.

Project teams that want to change their release model tag should do so
before the N1 milestone by submitting a patch to the project list in
the governance repository.

I've proposed a patch to the release tools to change the tag in
release announcement emails from "release" to "newrel". Please comment
on https://review.openstack.org/#/c/312762 if you have any thoughts
about that.

Release Actions
---

Release liaisons should add their name and contact information to
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

Release liaisons should configure their IRC clients to join
#openstack-release by default.

This is a good time to coordinate with the stable maintenance team on
releases from stable branches.

Important Dates
---

Newton 1 milestone: R-18 June 2

Newton release schedule: http://releases.openstack.org/newton/schedule.html

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


Re: [openstack-dev] [Cinder] Nominating Michał Dulko to Cinder Core

2016-05-05 Thread Mike Perez
On 13:16 May 03, Sean McGinnis wrote:
> Hey everyone,
> 
> I would like to nominate Michał Dulko to the Cinder core team. Michał's
> contributions with both code reviews [0] and code contributions [1] have
> been significant for some time now.

+1 welcome!

-- 
Mike Perez

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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Amrith Kumar
In a chat on the Infra channel there was a suggestion that we create an 
etherpad to track issues with DIB.

https://etherpad.openstack.org/p/image-generation-in-openstack

I’ve created an etherpad above and populated it with some information that I 
have. I’ll post the etherpad on the infra IRC channel as well.

Thanks,

-amrith

From: Michael Johnson [mailto:johnso...@gmail.com]
Sent: Thursday, May 05, 2016 12:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove

Just to chime in from an Octavia perspective as we were added to the subject.

We have not had issues with DIB.  There are things about the elements that 
could be improved, and we have been working on those over time.  Currently we 
build the image with DIB for our scenario test runs and devstack.

For images, we are investigating options to build smaller images, but again, I 
think DIB can support us in that and mostly it is work on elements.

Michael


On Thu, May 5, 2016 at 7:43 AM, Mariam John 
> wrote:

[Inactive hide details for Victoria Martínez de la Cruz ---05/05/2016 08:12:33 
AM---Hi all, A few things:]Victoria Martínez de la Cruz ---05/05/2016 08:12:33 
AM---Hi all, A few things:

From: Victoria Martínez de la Cruz 
>
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 05/05/2016 08:12 AM
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove





Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we should 
try to avoid changing tools unless highly necessary. The downsides we found for 
DIB are detailed in this spec [0] and Ethan (in this same thread) also added 
valid points on the Sahara case. My concern here is, should we stick with DIB 
just because is the standard for image creation? Shouldn't we take in 
consideration that some projects, like Sahara, are moving away from?

I think it would be worth trying to see if DIB can address the concerns raised 
by the different projects around image building and improve upon that. By 
improving DIB, I think all these projects and OpenStack in general can benefit 
from it.

- In the long term it would be ideal that we reach to a common solution for 
image creation for all the projects that need tailored images: Trove, Sahara, 
Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB for 
image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec is 
up there [0]. I think is his work to kick-off that repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar 
>:
As we discussed at summit, (and consistent with all of the comments) we should 
move ahead with the project to advance the image builder for Trove and make it 
easier to build guest images for Trove by leveraging the DIB elements that we 
have in trove-integration.



To that end, the infra [1] and governance [2] changes have been submitted for 
review. The Launchpad tracker [3] has been registered.



I am working on taking the existing DIB elements in trove-integration and 
putting them in the new repository (openstack/trove-image-builder). I am also 
going to continue to watch this conversation and record any shortcomings with 
the existing DIB elements in Launchpad [3] and work on fixing those as well. 
Pete mentions one in his earlier email and I’ve logged that in Launchpad [4].



Thanks,



-amrith



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

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

[3] https://launchpad.net/trove-image-builder

[4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454







From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Wednesday, May 04, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions) 
>

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove



The way I see this, these are the 2 main concerns I have been hearing regarding 
image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security

I dont think there is any argument regarding the benefits of moving the 
database elements to a seperate repository and packaging and managing them from 
there.

It looks like the case that we make for whether to use libguestfs or DIB for 
image building are in the technical 

Re: [openstack-dev] [nova][live migration] Request to merge initial storage pool patches

2016-05-05 Thread Matt Riedemann

On 5/5/2016 10:20 AM, Jay Pipes wrote:

On 05/05/2016 10:50 AM, Matthew Booth wrote:

TL;DR Core reviewers: please review the first 5 patches listed above.
There will be cake.


I only accept payment in cookies.

-jay

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



But they're called biscuits in the UK, right? So we're already greasing 
the wrong path.


--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [neutron][devstack] State of the refactor

2016-05-05 Thread Edgar Magana
Terrific decision! Thank a lot for all this great work.

Edgar




On 5/5/16, 9:12 AM, "Monty Taylor"  wrote:

>On 05/05/2016 10:57 AM, Sean M. Collins wrote:
>> During the Austin summit, there was a discussion in the QA meetings
>> about the future of Neutron's support in DevStack. It's been an ongoing
>> effort, and I'd like to step back and give everyone a view of the Big
>> Picture.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_newton-2Dqa-2Ddevstack-2Droadmap=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU=fRKjc7Z8RpVFg2mRBUCannAWvfPenic4UPOIk9Qe3Z8=
>>  
>>
>> A year ago at the NYC QA midcycle, consensus was reached that in order
>> to get Neutron to become the default deployment model for Devstack and
>> finally deprecate Nova-Network, some grunt work would need to be done to
>> clean up the DevStack code.
>>
>> Dean wrote about the experience in his blog:
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__hackstack.org_x_blog_2015_03_30_qa-2Dcode-2Dsprint=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU=ZlxFE_krg9WPuNtByMvCpfRYDpNrU2H6nr-7bBnNDrY=
>>  
>>
>>> DevStack's Neutron code is in bad shape. It has been continually
>>> updated by many people who do not understand the Big Picture. I blame
>>> myself for not staying on top of this code and allowing it to diverge
>>>from the rest of DevStack's style and implementation. Other Sean found
>>> a number of inconsistencies in variable names and uses as he tried to
>>> get the single interface work done and we came to the inevitable
>>> conclusion that it was time to start over.
>>
>> So we did.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_168438=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU=M0LvdXPXlRTXCdEr3sCq4VCoo7pQr7OhD_gv0tHHJf8=
>>  
>>
>> The new lib/neutron is an attempt to only have the *bare minimum*
>> configured for either an OVS or Linux Bridge deployment of Neutron. My
>> strategy was - start from scratch and build up enough Neutron
>> configuration to get everything to launch, and have the network plumbed
>> correctly. Everything else was left on the cutting room floor.
>>
>> There are still some things that I did for the sake of expediency, that
>> I am sure will need to be improved in the future. However, the code is
>> very close to completion - there's still some work that needs to be
>> done, but I see the light at the end of the tunnel.
>>
>> For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
>> share this view:
>>
>>> But what about the plugins? What about the advanced services? What
>>> about the vendors? I can't do it all at once. The first priority is to
>>> get a 'minimum viable Neutron' configuration to use as the default.
>>> The old code was renamed not removed, and exactly zero of the
>>> configuration variables and service names have changed. Nothing should
>>> be directly importing lib/neutron* so that change is handled in
>>> DevStack and Grenade already. After we have working linuxbridge and
>>> ovs configurations we can look at what else needs to be included.
>>
>> Sean Dague and I have also been kicking around some ideas about adding
>> another hook to the DevStack plugin contract so that DevStack plugins
>> that do network things have a chance to create networks and wire
>> everything during installation and configuration, as part of a DevStack
>> plugin call.
>>
>> The basic reasoning for this is, the current lib/neutron-legacy has tons
>> of knobs for plugging veths into things, creating provider networks,
>> etc.. - those things are very specific to a deployment or networking
>> type, so they should be moved into a plugin so they don't gunk up the
>> main code path and also avoid trampling one another (like they do
>> today).
>>
>> The current lib/neutron weighs in around 500 lines of code, and the l3
>> setup code (which was the nastiest) is 300 lines, split out into a
>> separate file. Partially to allow other plugins to call this code, and
>> partially because of a divide-and-conquer strategy I am employing for
>> the refactor.
>>
>> If you haven't read my post about eliminating the DevStack layer, this
>> is also part of my thought process for the refactor, and how to support
>> other configurations in DevStack.
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_pipermail_openstack-2Ddev_2016-2DApril_091764.html=CwICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=rQU0CNTLs59JVaD2xnR4lfhgqi7Bp567V_rp3eglXBU=WDOcyjDzV45GQClN_e5wsY2QKl5Re8wo0iZSEZ_uHsQ=
>>  
>>
>> So, take a look at what I've done so far, take it for a spin, and if you
>> have any 

Re: [openstack-dev] Requirements for becoming approved official project

2016-05-05 Thread Mike Perez
On 14:40 Apr 30, Shinobu Kinjo wrote:
> Hi Tom,
> 
> First sorry for bothering you -;
> 
> We are trying to make the tricircle project [1] one of the opnestack
> official projects. And we are referring to project team guide to make
> sure what are requirements. [2]. Reading this guide, what we need to
> consider right now is open development, I think (but not 100% sure).
> [3]

I think you're looking for:

http://governance.openstack.org/reference/tags/tc-approved-release.html

-- 
Mike Perez

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


[openstack-dev] [neutron][fwaas][vpnaas][lbaas][octavia] summit summary - future of the advanced services

2016-05-05 Thread Doug Wiegley
Egads, that’s a long subject prefix.  Anyways, we had a design session on the 
future of the advanced services:

https://etherpad.openstack.org/p/newton-neutron-future-adv-services

In a nutshell, vpn and fw are critically lacking active contributors at 
present. Again. A proposal was made to remove them from the neutron stadium, 
effectively making them the equivalent of stackforge projects (openstack 
experimental in the new terminology.)  This was rejected in favor of giving 
them until Ocata-1 to retain stadium status, similar to the criteria laid out 
in the later neutron stadium discussion:

https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution

Given how often we’ve extended the lives of those two repos by yet another six 
months, this time we’ll be looking for regular progress up to ocata-1, with 
final criteria being done (ish) by then. But, as agreed at the summit, if 
things go utterly dark post-summit, then you can expect to see governance 
patches to remove them from the stadium much faster than Ocata-1.

After that session, but worth mentioning here, further discussions led to a 
proposal to make lbaas a standalone project, with a standalone endpoint, but 
adopting the current API:

https://review.openstack.org/#/c/310805/
https://review.openstack.org/#/c/310667/

and here’s a WIP governance patch for flavor:

https://review.openstack.org/313056

This achieved broad consensus among those present for the follow-up 
conversations (-1 nits on that patch aside), but please comment on any of those 
if you have comments/concerns.

Next steps:

- Monitor progress of vpn and fw.
- Cleanup lbaas spinout specs, generate a timeline for minimum work required.

Thanks,
doug



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


Re: [openstack-dev] [tc] supporting Go

2016-05-05 Thread Clint Byrum
Excerpts from Hayes, Graham's message of 2016-05-05 07:26:26 -0700:
> On 04/05/2016 00:32, Hayes, Graham wrote:
> > On 03/05/2016 17:03, John Dickinson wrote:
> >> TC,
> >>
> >> In reference to 
> >> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html 
> >> and Thierry's reply, I'm currently drafting a TC resolution to update 
> >> http://governance.openstack.org/resolutions/20150901-programming-languages.html
> >>  to include Go as a supported language in OpenStack projects.
> >>
> >> As a starting point, what would you like to see addressed in the document 
> >> I'm drafting?
> >>
> >> --John
> >>
> >>
> >>
> >
> > Great - I was about to write a thread like this :)
> >
> > Designate is looking to move a single component of ours to Go - and we
> > were wondering what was the best way to do it.
> >
> > The current policy does allow for the TC to bless different languages
> > on a case by case basis - do we need to go from just python and JS to
> > allowing all projects to use go, or should the TC approve (or
> > disapprove) the swift and designate requests?
> >
> > I think the swift and designate changes might be a good test case to
> > see how the build / mirroring / packaging / artifact / library issues
> > shake out.
> >
> > - Graham
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> So, as part of the update to that policy, should we have an
> "OpenStack Go developer guide" that lays out how we think we will
> implement go in our stack.
> 
> I am sure it will not be complete, or even correct for what we actually
> do in the end, but it could give us a place to try and come to a shared
> understanding.
> 

I think I share your desire, to have something concrete on the table
before the TC (I'm not a TC member) considered this. However, I would
want to make sure the barrier isn't so high as to discourage progress.

I would love for the team(s) proposing Go code to provide whatever they
have now as a base for such a document. I would support the minimum
amount of effort to just reformat and reorganize that document so that
it resembles our python oriented guides, and start from there.

I doubt anyone not writing Go regularly will have much practical to
say about the details, but the community as a whole can review it and
be sure that the teams making the proposal share the same orientation
toward developers as we have for python development.

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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Michael Johnson
Just to chime in from an Octavia perspective as we were added to the
subject.

We have not had issues with DIB.  There are things about the elements that
could be improved, and we have been working on those over time.  Currently
we build the image with DIB for our scenario test runs and devstack.

For images, we are investigating options to build smaller images, but
again, I think DIB can support us in that and mostly it is work on elements.

Michael


On Thu, May 5, 2016 at 7:43 AM, Mariam John  wrote:

> [image: Inactive hide details for Victoria Martínez de la Cruz
> ---05/05/2016 08:12:33 AM---Hi all, A few things:]Victoria Martínez de la
> Cruz ---05/05/2016 08:12:33 AM---Hi all, A few things:
>
> From: Victoria Martínez de la Cruz 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 05/05/2016 08:12 AM
> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
> --
>
>
>
> Hi all,
>
> A few things:
>
> - I agree that moving from DIB to libguestfs is a bold move and that we
> should try to avoid changing tools unless highly necessary. The downsides
> we found for DIB are detailed in this spec [0] and Ethan (in this same
> thread) also added valid points on the Sahara case. My concern here is,
> should we stick with DIB just because is the standard for image creation?
> Shouldn't we take in consideration that some projects, like Sahara, are
> moving away from?
>
> *I think it would be worth trying to see if DIB can address the concerns
> raised by the different projects around image building and improve upon
> that. By improving DIB, I think all these projects and OpenStack in general
> can benefit from it. *
>
> - In the long term it would be ideal that we reach to a common solution
> for image creation for all the projects that need tailored images: Trove,
> Sahara, Octavia, Manila, and IIRC, Kolla and Cue.
> - In the short term, I'm on board or working on having tools based on DIB
> for image creation in Trove.
> - Amrith, Pete is working on the image creation process for Trove. The
> spec is up there [0]. I think is his work to kick-off that repository.
>
> Best,
>
> Victoria
>
> [0] *https://review.openstack.org/#/c/295274/*
> 
>
> 2016-05-04 23:20 GMT-03:00 Amrith Kumar <*amr...@tesora.com*
> >:
>
>As we discussed at summit, (and consistent with all of the comments)
>we should move ahead with the project to advance the image builder for
>Trove and make it easier to build guest images for Trove by leveraging the
>DIB elements that we have in trove-integration.
>
>
>
>To that end, the infra [1] and governance [2] changes have been
>submitted for review. The Launchpad tracker [3] has been registered.
>
>
>
>I am working on taking the existing DIB elements in trove-integration
>and putting them in the new repository (openstack/trove-image-builder). I
>am also going to continue to watch this conversation and record any
>shortcomings with the existing DIB elements in Launchpad [3] and work on
>fixing those as well. Pete mentions one in his earlier email and I’ve
>logged that in Launchpad [4].
>
>
>
>Thanks,
>
>
>
>-amrith
>
>
>
>[1] *https://review.openstack.org/#/c/312805/*
>
>
>[2] *https://review.openstack.org/#/c/312806/*
>
>
>[3] *https://launchpad.net/trove-image-builder*
>
>
>[4] *https://bugs.launchpad.net/trove-image-builder/+bug/1578454*
>
>
>
>
>
>
>
>
>*From:* Mariam John [mailto:*mari...@us.ibm.com* ]
> * Sent:* Wednesday, May 04, 2016 4:19 PM
> * To:* OpenStack Development Mailing List (not for usage questions) <
>*openstack-dev@lists.openstack.org* 
>>
>
>
> * Subject:* Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
>discussion of image building in Trove
>
>
>
>The way I see this, these are the 2 main concerns I have been hearing
>regarding image building in Trove:
>1) making the process simple and easy for users
>2) addressing the issue of security
>
>I dont think there is any argument regarding the benefits of moving
>the database elements to a seperate repository and packaging and managing
>them from there.
>
>It looks like the case that we make for whether to use libguestfs or
>DIB for image building are in the technical details of how image building
>happens and their nuances - assuming that ease of use & having a simple
>interface to build secure images matters most, I wonder if the end-users
>would be concerned about these 

Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go

2016-05-05 Thread Pete Zaitcev
On Wed, 4 May 2016 21:52:49 +
"Fox, Kevin M"  wrote:

> Swift is in a strange place where the api is implemented in a way to
> favor one particular vendor backend implementation.

Sorry, but I disagree with the above assessement. There is no one
particular vendor like that, because the only vendor of Swift source
is OpenStack, and vendors of pre-packaged Swift are legion, all equal:
Red Hat, HPe (Helion), SwiftStack, Mirantis, and more.

> I'd love to be able to plugin Swift into our sites, but because we
> can only have one, the various tradoffs have lead us to deploy RadosGW
> most of the time.

The fact that you succeeded in running OpenStack with RadosGW proves that
there is no issue here that impedes a development or use of OpenStack.
We at Red Hat will be happy to support an installation of OpenStack using
Ceph underpinning it as integrated storage solution. Or, an installation
that uses the OpenStack-released, reference implementation of Swift,
which we integrate too. We're flexible like that, according to the needs
of each customer.

-- Pete

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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Nordquist, Peter L
Hello all, I’m an Operator that has worked with DIB here for the last few 
months to get some working images for our Private Cloud.  The only major issue 
I could come up with at the summit was the way grub 0.97 is treated in the 
bootloader element.  For Centos 6, I had to find an element that could actually 
install grub 0.97 since when yum goes to update the kernel, it tries to update 
the grub config but not the extlinux config and in our cloud we need the VMs to 
stay updated.  I’m sure the elements I have locally could be useful but the 
current thinking in my organization is to deprecate our Centos 6 use as quickly 
as possible.

I’ve also run into an issue reported here [0] that makes installing a 
bootloader in Centos 6 a pain in either extlinux or grub 0.97.  That’s really a 
quirk of the OS packages I’m using to build the image but still an odd 
situation.  I’ve updated my VMs that build images to the Mitaka RDO release and 
with that release came the qemu-kvm-ev packages so I’m hopeful that these new 
packages might fix this bug.  If not I’ll have to keep using Ubuntu to build my 
Centos 6 images.

Security is a concern for sure but in my environment I have Jenkins spawn a VM 
in the cloud to build these images and I give these VMs enough ram to build the 
image in memory instead of copying the image to disk.

I also have a requirement to standardize our images to using XFS for the root 
partition due to our flavors including a large amount of root disk.  The 
reasoning here is that XFS resizes faster than ext4 so I would have a concern 
if libguestfs could not do this.  It seems like I could just use DIB to fix any 
images that were created from your libguestfs scripts though so it might not be 
that much of a concern.

[0]: https://bugs.launchpad.net/diskimage-builder/+bug/1477179

Peter Nordquist

From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Thursday, May 05, 2016 07:43
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove


[Inactive hide details for Victoria Martínez de la Cruz ---05/05/2016 08:12:33 
AM---Hi all, A few things:]Victoria Martínez de la Cruz ---05/05/2016 08:12:33 
AM---Hi all, A few things:

From: Victoria Martínez de la Cruz 
>
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 05/05/2016 08:12 AM
Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove





Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we should 
try to avoid changing tools unless highly necessary. The downsides we found for 
DIB are detailed in this spec [0] and Ethan (in this same thread) also added 
valid points on the Sahara case. My concern here is, should we stick with DIB 
just because is the standard for image creation? Shouldn't we take in 
consideration that some projects, like Sahara, are moving away from?

I think it would be worth trying to see if DIB can address the concerns raised 
by the different projects around image building and improve upon that. By 
improving DIB, I think all these projects and OpenStack in general can benefit 
from it.

- In the long term it would be ideal that we reach to a common solution for 
image creation for all the projects that need tailored images: Trove, Sahara, 
Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB for 
image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec is 
up there [0]. I think is his work to kick-off that repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar 
>:
As we discussed at summit, (and consistent with all of the comments) we should 
move ahead with the project to advance the image builder for Trove and make it 
easier to build guest images for Trove by leveraging the DIB elements that we 
have in trove-integration.



To that end, the infra [1] and governance [2] changes have been submitted for 
review. The Launchpad tracker [3] has been registered.



I am working on taking the existing DIB elements in trove-integration and 
putting them in the new repository (openstack/trove-image-builder). I am also 
going to continue to watch this conversation and record any shortcomings with 
the existing DIB elements in Launchpad [3] and work on fixing those as well. 
Pete mentions one in his earlier email and I’ve logged that in Launchpad [4].



Thanks,



-amrith



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

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

[3] 

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Matthew Van Dijk
In the scenario of Trove supporting both tools what do you expect the
requirements for adding support for new databases will be? Are we
expecting to have to support both tools for approval from the
community?

Cheers,

Matt

On May 5, 2016, at 10:43 AM, Mariam John 
> wrote:


Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A 
few things:

From:  Victoria Martínez de la Cruz 
>
To:  "OpenStack Development Mailing List (not for usage questions)" 
>
Date:  05/05/2016 08:12 AM
Subject:  Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] 
discussion of image building in Trove





Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we should 
try to avoid changing tools unless highly necessary. The downsides we found for 
DIB are detailed in this spec [0] and Ethan (in this same thread) also added 
valid points on the Sahara case. My concern here is, should we stick with DIB 
just because is the standard for image creation? Shouldn't we take in 
consideration that some projects, like Sahara, are moving away from?

I think it would be worth trying to see if DIB can address the concerns raised 
by the different projects around image building and improve upon that. By 
improving DIB, I think all these projects and OpenStack in general can benefit 
from it.

- In the long term it would be ideal that we reach to a common solution for 
image creation for all the projects that need tailored images: Trove, Sahara, 
Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB for 
image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec is 
up there [0]. I think is his work to kick-off that repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar 
>:

As we discussed at summit, (and consistent with all of the comments) we should 
move ahead with the project to advance the image builder for Trove and make it 
easier to build guest images for Trove by leveraging the DIB elements that we 
have in trove-integration.


To that end, the infra [1] and governance [2] changes have been submitted for 
review. The Launchpad tracker [3] has been registered.



I am working on taking the existing DIB elements in trove-integration and 
putting them in the new repository (openstack/trove-image-builder). I am also 
going to continue to watch this conversation and record any shortcomings with 
the existing DIB elements in Launchpad [3] and work on fixing those as well. 
Pete mentions one in his earlier email and I’ve logged that in Launchpad [4].



Thanks,



-amrith



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

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

[3] https://launchpad.net/trove-image-builder

[4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454





From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Wednesday, May 04, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions) 
>

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove



The way I see this, these are the 2 main concerns I have been hearing regarding 
image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security

I dont think there is any argument regarding the benefits of moving the 
database elements to a seperate repository and packaging and managing them from 
there.

It looks like the case that we make for whether to use libguestfs or DIB for 
image building are in the technical details of how image building happens and 
their nuances - assuming that ease of use & having a simple interface to build 
secure images matters most, I wonder if the end-users would be concerned about 
these details.

By addressing some of the issues like:
- moving the Trove elements to a new repository
- adding support for new distros
- creating a wrapper script for building an image -getting the Trove guest 
agent code & configuration files
- managing environment variables better

I believe it will make a huge improvement in terms of simplifying and improving 
the ease of use for end users and hence could be the low hanging fruit that we 
can implement in the mean time. I agree that switching from DIB to any other 
tool is a big step and we need to put alot of thought into it like many others 
have suggested. Like Pete mentioned earlier in one of the links, there are 
couple of other tools available for building images. I am sure we could make 
the case for 

Re: [openstack-dev] [neutron][devstack] State of the refactor

2016-05-05 Thread Kyle Mestery
On Thu, May 5, 2016 at 11:12 AM, Monty Taylor  wrote:
> On 05/05/2016 10:57 AM, Sean M. Collins wrote:
>>
>> During the Austin summit, there was a discussion in the QA meetings
>> about the future of Neutron's support in DevStack. It's been an ongoing
>> effort, and I'd like to step back and give everyone a view of the Big
>> Picture.
>>
>> https://etherpad.openstack.org/p/newton-qa-devstack-roadmap
>>
>> A year ago at the NYC QA midcycle, consensus was reached that in order
>> to get Neutron to become the default deployment model for Devstack and
>> finally deprecate Nova-Network, some grunt work would need to be done to
>> clean up the DevStack code.
>>
>> Dean wrote about the experience in his blog:
>>
>> http://hackstack.org/x/blog/2015/03/30/qa-code-sprint
>>
>>> DevStack's Neutron code is in bad shape. It has been continually
>>> updated by many people who do not understand the Big Picture. I blame
>>> myself for not staying on top of this code and allowing it to diverge
>>> from the rest of DevStack's style and implementation. Other Sean found
>>> a number of inconsistencies in variable names and uses as he tried to
>>> get the single interface work done and we came to the inevitable
>>> conclusion that it was time to start over.
>>
>>
>> So we did.
>>
>> https://review.openstack.org/168438
>>
>> The new lib/neutron is an attempt to only have the *bare minimum*
>> configured for either an OVS or Linux Bridge deployment of Neutron. My
>> strategy was - start from scratch and build up enough Neutron
>> configuration to get everything to launch, and have the network plumbed
>> correctly. Everything else was left on the cutting room floor.
>>
>> There are still some things that I did for the sake of expediency, that
>> I am sure will need to be improved in the future. However, the code is
>> very close to completion - there's still some work that needs to be
>> done, but I see the light at the end of the tunnel.
>>
>> For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
>> share this view:
>>
>>> But what about the plugins? What about the advanced services? What
>>> about the vendors? I can't do it all at once. The first priority is to
>>> get a 'minimum viable Neutron' configuration to use as the default.
>>> The old code was renamed not removed, and exactly zero of the
>>> configuration variables and service names have changed. Nothing should
>>> be directly importing lib/neutron* so that change is handled in
>>> DevStack and Grenade already. After we have working linuxbridge and
>>> ovs configurations we can look at what else needs to be included.
>>
>>
>> Sean Dague and I have also been kicking around some ideas about adding
>> another hook to the DevStack plugin contract so that DevStack plugins
>> that do network things have a chance to create networks and wire
>> everything during installation and configuration, as part of a DevStack
>> plugin call.
>>
>> The basic reasoning for this is, the current lib/neutron-legacy has tons
>> of knobs for plugging veths into things, creating provider networks,
>> etc.. - those things are very specific to a deployment or networking
>> type, so they should be moved into a plugin so they don't gunk up the
>> main code path and also avoid trampling one another (like they do
>> today).
>>
>> The current lib/neutron weighs in around 500 lines of code, and the l3
>> setup code (which was the nastiest) is 300 lines, split out into a
>> separate file. Partially to allow other plugins to call this code, and
>> partially because of a divide-and-conquer strategy I am employing for
>> the refactor.
>>
>> If you haven't read my post about eliminating the DevStack layer, this
>> is also part of my thought process for the refactor, and how to support
>> other configurations in DevStack.
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html
>>
>> So, take a look at what I've done so far, take it for a spin, and if you
>> have any thoughts or ideas please share them!
>
>
> Everything about this is the best thing that has ever happened since the
> dawn of time.
>

<3

>
>
> __
> OpenStack Development Mailing List (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] License for specs repo

2016-05-05 Thread Daniel P. Berrange
On Thu, May 05, 2016 at 12:03:38PM -0400, Ben Swartzlander wrote:
> It appears that many of the existing specs repos contain a confusing mixture
> of Apache 2.0 licensed code and Creative Commons licensed docs.
> 
> The official cookie-cutter for creating new specs repos [1] appears to also
> contain a mixture of the two licenses, although it's even more confusing
> because it seems an attempt was made to change the license from Apache to
> Creative Commons [2] yet there are still several [3] places [4] where Apache
> is clearly specified.
> 
> I personally have no opinion on what license should be used, but I'd like to
> clearly specify the license for the newly-created manila-specs repo, and I'm
> happy with whatever the TC is currently recommending.

Content in the specs is often used as the basis for writing official
documentation later, so license compatibility with docs is an important
consideration. IIUC the official OpenStack manuals are Apache licensed,
while other open source 3rd party docs are often CC licensed.

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] [neutron][devstack] State of the refactor

2016-05-05 Thread Doug Wiegley

> On May 5, 2016, at 8:57 AM, Sean M. Collins  wrote:
> 
> During the Austin summit, there was a discussion in the QA meetings
> about the future of Neutron's support in DevStack. It's been an ongoing
> effort, and I'd like to step back and give everyone a view of the Big
> Picture.
> 
> https://etherpad.openstack.org/p/newton-qa-devstack-roadmap
> 
> A year ago at the NYC QA midcycle, consensus was reached that in order
> to get Neutron to become the default deployment model for Devstack and
> finally deprecate Nova-Network, some grunt work would need to be done to
> clean up the DevStack code.
> 
> Dean wrote about the experience in his blog:
> 
> http://hackstack.org/x/blog/2015/03/30/qa-code-sprint
> 
>> DevStack's Neutron code is in bad shape. It has been continually
>> updated by many people who do not understand the Big Picture. I blame
>> myself for not staying on top of this code and allowing it to diverge
>> from the rest of DevStack's style and implementation. Other Sean found
>> a number of inconsistencies in variable names and uses as he tried to
>> get the single interface work done and we came to the inevitable
>> conclusion that it was time to start over.
> 
> So we did.
> 
> https://review.openstack.org/168438
> 
> The new lib/neutron is an attempt to only have the *bare minimum*
> configured for either an OVS or Linux Bridge deployment of Neutron. My

I’d actually suggest just linuxbridge (the install guide default), and make the 
OVS jobs use whatever mechanism the other plugins will have to use.

Thanks,
doug


> strategy was - start from scratch and build up enough Neutron
> configuration to get everything to launch, and have the network plumbed
> correctly. Everything else was left on the cutting room floor.
> 
> There are still some things that I did for the sake of expediency, that
> I am sure will need to be improved in the future. However, the code is
> very close to completion - there's still some work that needs to be
> done, but I see the light at the end of the tunnel.
> 
> For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
> share this view:
> 
>> But what about the plugins? What about the advanced services? What
>> about the vendors? I can't do it all at once. The first priority is to
>> get a 'minimum viable Neutron' configuration to use as the default.
>> The old code was renamed not removed, and exactly zero of the
>> configuration variables and service names have changed. Nothing should
>> be directly importing lib/neutron* so that change is handled in
>> DevStack and Grenade already. After we have working linuxbridge and
>> ovs configurations we can look at what else needs to be included.
> 
> Sean Dague and I have also been kicking around some ideas about adding
> another hook to the DevStack plugin contract so that DevStack plugins
> that do network things have a chance to create networks and wire
> everything during installation and configuration, as part of a DevStack
> plugin call.
> 
> The basic reasoning for this is, the current lib/neutron-legacy has tons
> of knobs for plugging veths into things, creating provider networks,
> etc.. - those things are very specific to a deployment or networking
> type, so they should be moved into a plugin so they don't gunk up the
> main code path and also avoid trampling one another (like they do
> today).
> 
> The current lib/neutron weighs in around 500 lines of code, and the l3
> setup code (which was the nastiest) is 300 lines, split out into a
> separate file. Partially to allow other plugins to call this code, and
> partially because of a divide-and-conquer strategy I am employing for
> the refactor.
> 
> If you haven't read my post about eliminating the DevStack layer, this
> is also part of my thought process for the refactor, and how to support
> other configurations in DevStack.
> 
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html
> 
> So, take a look at what I've done so far, take it for a spin, and if you
> have any thoughts or ideas please share them! 
> 
> -- 
> Sean M. Collins
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


Re: [openstack-dev] [neutron][devstack] State of the refactor

2016-05-05 Thread Ricardo Carrillo Cruz
Yeah, seriously, thanks a million for this.
You are making developers lives wa better!

2016-05-05 18:12 GMT+02:00 Monty Taylor :

> On 05/05/2016 10:57 AM, Sean M. Collins wrote:
>
>> During the Austin summit, there was a discussion in the QA meetings
>> about the future of Neutron's support in DevStack. It's been an ongoing
>> effort, and I'd like to step back and give everyone a view of the Big
>> Picture.
>>
>> https://etherpad.openstack.org/p/newton-qa-devstack-roadmap
>>
>> A year ago at the NYC QA midcycle, consensus was reached that in order
>> to get Neutron to become the default deployment model for Devstack and
>> finally deprecate Nova-Network, some grunt work would need to be done to
>> clean up the DevStack code.
>>
>> Dean wrote about the experience in his blog:
>>
>> http://hackstack.org/x/blog/2015/03/30/qa-code-sprint
>>
>> DevStack's Neutron code is in bad shape. It has been continually
>>> updated by many people who do not understand the Big Picture. I blame
>>> myself for not staying on top of this code and allowing it to diverge
>>> from the rest of DevStack's style and implementation. Other Sean found
>>> a number of inconsistencies in variable names and uses as he tried to
>>> get the single interface work done and we came to the inevitable
>>> conclusion that it was time to start over.
>>>
>>
>> So we did.
>>
>> https://review.openstack.org/168438
>>
>> The new lib/neutron is an attempt to only have the *bare minimum*
>> configured for either an OVS or Linux Bridge deployment of Neutron. My
>> strategy was - start from scratch and build up enough Neutron
>> configuration to get everything to launch, and have the network plumbed
>> correctly. Everything else was left on the cutting room floor.
>>
>> There are still some things that I did for the sake of expediency, that
>> I am sure will need to be improved in the future. However, the code is
>> very close to completion - there's still some work that needs to be
>> done, but I see the light at the end of the tunnel.
>>
>> For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
>> share this view:
>>
>> But what about the plugins? What about the advanced services? What
>>> about the vendors? I can't do it all at once. The first priority is to
>>> get a 'minimum viable Neutron' configuration to use as the default.
>>> The old code was renamed not removed, and exactly zero of the
>>> configuration variables and service names have changed. Nothing should
>>> be directly importing lib/neutron* so that change is handled in
>>> DevStack and Grenade already. After we have working linuxbridge and
>>> ovs configurations we can look at what else needs to be included.
>>>
>>
>> Sean Dague and I have also been kicking around some ideas about adding
>> another hook to the DevStack plugin contract so that DevStack plugins
>> that do network things have a chance to create networks and wire
>> everything during installation and configuration, as part of a DevStack
>> plugin call.
>>
>> The basic reasoning for this is, the current lib/neutron-legacy has tons
>> of knobs for plugging veths into things, creating provider networks,
>> etc.. - those things are very specific to a deployment or networking
>> type, so they should be moved into a plugin so they don't gunk up the
>> main code path and also avoid trampling one another (like they do
>> today).
>>
>> The current lib/neutron weighs in around 500 lines of code, and the l3
>> setup code (which was the nastiest) is 300 lines, split out into a
>> separate file. Partially to allow other plugins to call this code, and
>> partially because of a divide-and-conquer strategy I am employing for
>> the refactor.
>>
>> If you haven't read my post about eliminating the DevStack layer, this
>> is also part of my thought process for the refactor, and how to support
>> other configurations in DevStack.
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html
>>
>> So, take a look at what I've done so far, take it for a spin, and if you
>> have any thoughts or ideas please share them!
>>
>
> Everything about this is the best thing that has ever happened since the
> dawn of time.
>
>
>
> __
> OpenStack Development Mailing List (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][devstack] State of the refactor

2016-05-05 Thread Monty Taylor

On 05/05/2016 10:57 AM, Sean M. Collins wrote:

During the Austin summit, there was a discussion in the QA meetings
about the future of Neutron's support in DevStack. It's been an ongoing
effort, and I'd like to step back and give everyone a view of the Big
Picture.

https://etherpad.openstack.org/p/newton-qa-devstack-roadmap

A year ago at the NYC QA midcycle, consensus was reached that in order
to get Neutron to become the default deployment model for Devstack and
finally deprecate Nova-Network, some grunt work would need to be done to
clean up the DevStack code.

Dean wrote about the experience in his blog:

http://hackstack.org/x/blog/2015/03/30/qa-code-sprint


DevStack's Neutron code is in bad shape. It has been continually
updated by many people who do not understand the Big Picture. I blame
myself for not staying on top of this code and allowing it to diverge
from the rest of DevStack's style and implementation. Other Sean found
a number of inconsistencies in variable names and uses as he tried to
get the single interface work done and we came to the inevitable
conclusion that it was time to start over.


So we did.

https://review.openstack.org/168438

The new lib/neutron is an attempt to only have the *bare minimum*
configured for either an OVS or Linux Bridge deployment of Neutron. My
strategy was - start from scratch and build up enough Neutron
configuration to get everything to launch, and have the network plumbed
correctly. Everything else was left on the cutting room floor.

There are still some things that I did for the sake of expediency, that
I am sure will need to be improved in the future. However, the code is
very close to completion - there's still some work that needs to be
done, but I see the light at the end of the tunnel.

For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
share this view:


But what about the plugins? What about the advanced services? What
about the vendors? I can't do it all at once. The first priority is to
get a 'minimum viable Neutron' configuration to use as the default.
The old code was renamed not removed, and exactly zero of the
configuration variables and service names have changed. Nothing should
be directly importing lib/neutron* so that change is handled in
DevStack and Grenade already. After we have working linuxbridge and
ovs configurations we can look at what else needs to be included.


Sean Dague and I have also been kicking around some ideas about adding
another hook to the DevStack plugin contract so that DevStack plugins
that do network things have a chance to create networks and wire
everything during installation and configuration, as part of a DevStack
plugin call.

The basic reasoning for this is, the current lib/neutron-legacy has tons
of knobs for plugging veths into things, creating provider networks,
etc.. - those things are very specific to a deployment or networking
type, so they should be moved into a plugin so they don't gunk up the
main code path and also avoid trampling one another (like they do
today).

The current lib/neutron weighs in around 500 lines of code, and the l3
setup code (which was the nastiest) is 300 lines, split out into a
separate file. Partially to allow other plugins to call this code, and
partially because of a divide-and-conquer strategy I am employing for
the refactor.

If you haven't read my post about eliminating the DevStack layer, this
is also part of my thought process for the refactor, and how to support
other configurations in DevStack.

http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html

So, take a look at what I've done so far, take it for a spin, and if you
have any thoughts or ideas please share them!


Everything about this is the best thing that has ever happened since the 
dawn of time.



__
OpenStack Development Mailing List (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][devstack] State of the refactor

2016-05-05 Thread Sean M. Collins
During the Austin summit, there was a discussion in the QA meetings
about the future of Neutron's support in DevStack. It's been an ongoing
effort, and I'd like to step back and give everyone a view of the Big
Picture.

https://etherpad.openstack.org/p/newton-qa-devstack-roadmap

A year ago at the NYC QA midcycle, consensus was reached that in order
to get Neutron to become the default deployment model for Devstack and
finally deprecate Nova-Network, some grunt work would need to be done to
clean up the DevStack code.

Dean wrote about the experience in his blog:

http://hackstack.org/x/blog/2015/03/30/qa-code-sprint

>DevStack's Neutron code is in bad shape. It has been continually
>updated by many people who do not understand the Big Picture. I blame
>myself for not staying on top of this code and allowing it to diverge
>from the rest of DevStack's style and implementation. Other Sean found
>a number of inconsistencies in variable names and uses as he tried to
>get the single interface work done and we came to the inevitable
>conclusion that it was time to start over.

So we did.

https://review.openstack.org/168438

The new lib/neutron is an attempt to only have the *bare minimum*
configured for either an OVS or Linux Bridge deployment of Neutron. My
strategy was - start from scratch and build up enough Neutron
configuration to get everything to launch, and have the network plumbed
correctly. Everything else was left on the cutting room floor.

There are still some things that I did for the sake of expediency, that
I am sure will need to be improved in the future. However, the code is
very close to completion - there's still some work that needs to be
done, but I see the light at the end of the tunnel.

For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
share this view:

> But what about the plugins? What about the advanced services? What
> about the vendors? I can't do it all at once. The first priority is to
> get a 'minimum viable Neutron' configuration to use as the default.
> The old code was renamed not removed, and exactly zero of the
> configuration variables and service names have changed. Nothing should
> be directly importing lib/neutron* so that change is handled in
> DevStack and Grenade already. After we have working linuxbridge and
> ovs configurations we can look at what else needs to be included.

Sean Dague and I have also been kicking around some ideas about adding
another hook to the DevStack plugin contract so that DevStack plugins
that do network things have a chance to create networks and wire
everything during installation and configuration, as part of a DevStack
plugin call.

The basic reasoning for this is, the current lib/neutron-legacy has tons
of knobs for plugging veths into things, creating provider networks,
etc.. - those things are very specific to a deployment or networking
type, so they should be moved into a plugin so they don't gunk up the
main code path and also avoid trampling one another (like they do
today).

The current lib/neutron weighs in around 500 lines of code, and the l3
setup code (which was the nastiest) is 300 lines, split out into a
separate file. Partially to allow other plugins to call this code, and
partially because of a divide-and-conquer strategy I am employing for
the refactor.

If you haven't read my post about eliminating the DevStack layer, this
is also part of my thought process for the refactor, and how to support
other configurations in DevStack.

http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html

So, take a look at what I've done so far, take it for a spin, and if you
have any thoughts or ideas please share them! 

-- 
Sean M. Collins

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


[openstack-dev] [tc] License for specs repo

2016-05-05 Thread Ben Swartzlander
It appears that many of the existing specs repos contain a confusing 
mixture of Apache 2.0 licensed code and Creative Commons licensed docs.


The official cookie-cutter for creating new specs repos [1] appears to 
also contain a mixture of the two licenses, although it's even more 
confusing because it seems an attempt was made to change the license 
from Apache to Creative Commons [2] yet there are still several [3] 
places [4] where Apache is clearly specified.


I personally have no opinion on what license should be used, but I'd 
like to clearly specify the license for the newly-created manila-specs 
repo, and I'm happy with whatever the TC is currently recommending.


-Ben Swartzlander

[1] https://github.com/openstack-dev/specs-cookiecutter
[2] 
https://github.com/openstack-dev/specs-cookiecutter/commit/8738f58981da3ad9c0f27fb545d61747213482a4#diff-053c5863d526dd5103cd9b0069074596
[3] 
https://github.com/openstack-dev/specs-cookiecutter/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/setup.cfg#L12
[4] 
https://github.com/openstack-dev/specs-cookiecutter/blob/master/README.rst


__
OpenStack Development Mailing List (not for 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][devstack] State of the refactor

2016-05-05 Thread Sean M. Collins
Here is the patch I'm using to test the refactor against the Neutron
CI jobs.

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

There is still some work to be done, and it shows.
-- 
Sean M. Collins

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


Re: [openstack-dev] [nova][live migration] Request to merge initial storage pool patches

2016-05-05 Thread Jay Pipes

On 05/05/2016 10:50 AM, Matthew Booth wrote:

TL;DR Core reviewers: please review the first 5 patches listed above.
There will be cake.


I only accept payment in cookies.

-jay

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


Re: [openstack-dev] [Infra][Kuryr] - Sub repositories

2016-05-05 Thread Andreas Jaeger

On 05/05/2016 01:17 PM, Gal Sagie wrote:

Hello all,

Following the summit discussions and after summit checking we decided
its better for us
to try a sub repositories model for Kuryr (better for packaging and
requirement/dependencies management).


What do you mean with sub repositories?



We would like to create additional sub repositories under Kuryr and i
was wondering if the correct
process would be to just create different new projects following [1] and
then update
the governance repository for Kuryr (attaching all these projects as
deliverable of Kuryr).

Or is there a better/simpler method to do this?


That's the way to add repositories to your project,

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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


Re: [openstack-dev] [horizon] Angular form framework

2016-05-05 Thread Michael Krotscheck
This feels like a thing for AngularJS projects only, yes? What about
projects like Fuel that use React?

Michael

On Wed, May 4, 2016 at 9:00 PM Tripp, Travis S  wrote:

> Hello everybody,
>
> I sent a message about this direclty to a couple of people for their quick
> thoughts. It looks like there is enough interest that I should have just
> sent it to the whole ML from the start. I’d like to keep folks in the loop,
> so, I’m copying it all below with all of the responses To date.
>
> Thanks,
> Travis
>
> From: "Borland, Matt" >
>
> That sounds great, it would be good to use something we don’t have to
> maintain.  Timur, thanks for researching that!
>
> Matt
>
> From: Timur Sufiev [mailto:tsuf...@mirantis.com]
>
> Folks,
>
> I was going to research this library as the possible prerequisite to
> angularization murano-dashboard 'dynamic ui' feature. So i'm planning to
> start next week looking into it.
>
> On Mon, 2 May 2016 at 20:21, Thai Q Tran > wrote:
> I think that it will remove a lot of boilerplate HTML, and is much more
> extensible than the current way of creating forms. But we may need to
> extend the directive to do more things.
>
> The options they provide does not cover the 2 cases that I brought up.
> hz-password and hz-if-* are both directives.
> For example: 
>
> This says that if some_rules passes, then show this input, otherwise, hide
> it. Essentially, what we need is the ability to inject additional attrs
> into each form field so that we can include our own directives. If we can
> somehow extend ngSchemaForm to support this, it should work.
>
> Alternately, we can do the policy check in javascript instead. It just
> means we have to use the services directly rather than their directive
> counterparts (most of the directives we have are backed by a service, i.e.
> hz-if-policy uses the policy service). It's less nice but should also work.
>
> Ultimately, I think going this direction is right, as the extensible
> benefits outweighs the declarative readability. There is still a separation
> of concerns, the forms can be declare like how we declare actions today (in
> a service that we can extend).
>
> - Original message -
> From: "Rob Cresswell (rcresswe)" >
>
> I’m a pretty big fan of this idea, I’ve mentioned it at basically every
> meet up we’ve had. Building up content like this is a great way of
> preventing duplication.
>
> Thai, the forms can take specific conditions to control their display:
> https://github.com/json-schema-form/angular-schema-form/blob/master/docs/index.md#standard-options
> as well as custom form fields, so it looks like that solves both of your
> issues?
>
> Rob
>
> On 27 Apr 2016, at 11:44, tsuf...@mirantis.com
> wrote:
>
> I recall mentioning model-directed generation of forms layout (since they
> are pretty verbose) at Hillsboro midcycle, the response was that 'mixing
> logic/model and presentation is not the best pattern'.
>
> On Wed, Apr 27, 2016 at 7:41 PM Thai Q Tran > wrote:
> Looks interesting, but I'm not too sure it will work for all cases. I can
> think of a few cases where this might not work.
>
> Case 1. We have custom directives that modify existing input forms such as
> hz-password. Not sure how we will be able to incorporate it if we use an
> auto-generated form.
>
> Case 2. We have things like hz-if that we may use to control which form
> fields to show. Again, not sure how this will work if we are
> auto-generating the form. I suppose you would have to do the check in the
> controller and modify the JSON to reflect this. But that will make it less
> declarative.
>
> - Original message -
> From: "Tripp, Travis S"  >>
>
> Alex Tivelkov at Mirantis mentioned this to me.  Has anybody looked at
> this to see if it is something we might want to incorporate. He said it
> allows using JSON schema definitions to generate forms.  As FYI, the
> Metadata Definitions in Glance are in JSON schema format and many of the
> services actually provide JSON schema of their fields.
> ar form framework
>
> http://schemaform.io
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova][live migration] Request to merge initial storage pool patches

2016-05-05 Thread Matthew Booth
I mentioned in the meeting last Tuesday that there are now 2 of us working
on the persistent storage metadata patches: myself and Diana Clarke. I've
also been talking to Paul Carlton today trying to work out how he can get
moving with the subsequent libvirt storage pools work without a huge amount
of conflict. We're going to work that out, but something which would help
us enormously while we work together is to knock off some semi-dependent
patches at the beginning of the series.

Specifically there are 5 patches which precede the series. None of these 5
patches are really part of the series, but the series depends on all 5 to a
greater or lesser degree. In order, they are:

Only attempt to inject files if the injection disk exists
https://review.openstack.org/#/c/250872/

Remove fake_imagebackend.Raw and cleanup dependent tests
https://review.openstack.org/#/c/267661/

Rename Image.check_image_exists to Image.exists()
https://review.openstack.org/#/c/270998/

Rename Raw backend to NoBacking
https://review.openstack.org/#/c/279626/

Remove deprecated option libvirt.remove_unused_kernels
https://review.openstack.org/#/c/265886/

These have all been reviewed previously and attracted +1s. I just rebased
them, so they may have been lost, but I'm pretty sure they're ready for
prime time. These patches aren't really what the series is about, but they
are currently the principal source of merge conflicts. If we could get
these out of the way it would make it much easier for the 3 of us working
on the substantive series. Any chance of some core reviewer attention to
get these moving?

As for the status of the rest of the series, there are 2 more which I don't
expect to change:

Add a lock() context manager to image backend
https://review.openstack.org/#/c/279625/

Introduce ImageCacheLocalPool
https://review.openstack.org/#/c/279669/

Please review these too. However, these patches aren't ready to be merged
because they don't add users of the interfaces they introduce.

Everything after that is definitely changing. Diana and I are currently
working on cranking through these backend by backend. I'll provide a weekly
progress update in the live migration meeting.

TL;DR Core reviewers: please review the first 5 patches listed above. There
will be cake.

Thanks,

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Mariam John




From:   Victoria Martínez de la Cruz 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   05/05/2016 08:12 AM
Subject:Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove



Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we
should try to avoid changing tools unless highly necessary. The downsides
we found for DIB are detailed in this spec [0] and Ethan (in this same
thread) also added valid points on the Sahara case. My concern here is,
should we stick with DIB just because is the standard for image creation?
Shouldn't we take in consideration that some projects, like Sahara, are
moving away from?

I think it would be worth trying to see if DIB can address the concerns
raised by the different projects around image building and improve upon
that. By improving DIB, I think all these projects and OpenStack in general
can benefit from it.

- In the long term it would be ideal that we reach to a common solution for
image creation for all the projects that need tailored images: Trove,
Sahara, Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB
for image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec
is up there [0]. I think is his work to kick-off that repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar :
  As we discussed at summit, (and consistent with all of the comments) we
  should move ahead with the project to advance the image builder for Trove
  and make it easier to build guest images for Trove by leveraging the DIB
  elements that we have in trove-integration.





  To that end, the infra [1] and governance [2] changes have been submitted
  for review. The Launchpad tracker [3] has been registered.





  I am working on taking the existing DIB elements in trove-integration and
  putting them in the new repository (openstack/trove-image-builder). I am
  also going to continue to watch this conversation and record any
  shortcomings with the existing DIB elements in Launchpad [3] and work on
  fixing those as well. Pete mentions one in his earlier email and I’ve
  logged that in Launchpad [4].





  Thanks,





  -amrith





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


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


  [3] https://launchpad.net/trove-image-builder


  [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454











  From: Mariam John [mailto:mari...@us.ibm.com]
  Sent: Wednesday, May 04, 2016 4:19 PM
  To: OpenStack Development Mailing List (not for usage questions) <
  openstack-dev@lists.openstack.org>



  Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
  discussion of image building in Trove





  The way I see this, these are the 2 main concerns I have been hearing
  regarding image building in Trove:
  1) making the process simple and easy for users
  2) addressing the issue of security

  I dont think there is any argument regarding the benefits of moving the
  database elements to a seperate repository and packaging and managing
  them from there.

  It looks like the case that we make for whether to use libguestfs or DIB
  for image building are in the technical details of how image building
  happens and their nuances - assuming that ease of use & having a simple
  interface to build secure images matters most, I wonder if the end-users
  would be concerned about these details.

  By addressing some of the issues like:
  - moving the Trove elements to a new repository
  - adding support for new distros
  - creating a wrapper script for building an image -getting the Trove
  guest agent code & configuration files
  - managing environment variables better

  I believe it will make a huge improvement in terms of simplifying and
  improving the ease of use for end users and hence could be the low
  hanging fruit that we can implement in the mean time. I agree that
  switching from DIB to any other tool is a big step and we need to put
  alot of thought into it like many others have suggested. Like Pete
  mentioned earlier in one of the links, there are couple of other tools
  available for building images. I am sure we could make the case for each
  of these tools and how it is easier/faster/better than the others. If we
  go down this route experimenting with libguestfs, is there anything
  stopping us couple of releases down the lane from wanting to experiment
  with some other tool because libguestfs doesn't perform well? The end
  user could use any tool they want to use to create images if they wish to
  do so but I agree and believe that Trove should support a standard way of
  building images (DIB being an OpenStack 

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Victoria Martínez de la Cruz
We agreed during the summit that we were going to amend the spec to reflect
latest discussions with regards to having DIB as a primary implementation
and adding support for libguestfs in parallel. The spec blueprint is named
"Trove image builder" and it's about building images and not about which
tool we are going to use. Thanks for creating the artifacts we need to push
the code, we take it over from there.

2016-05-05 11:12 GMT-03:00 Amrith Kumar :

>
>
> *From:* Victoria Martínez de la Cruz [mailto:
> victo...@vmartinezdelacruz.com]
> *Sent:* Thursday, May 05, 2016 9:00 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
>
>
>
> Hi all,
>
>
>
> A few things:
>
>
>
> - I agree that moving from DIB to libguestfs is a bold move and that we
> should try to avoid changing tools unless highly necessary. The downsides
> we found for DIB are detailed in this spec [0] and Ethan (in this same
> thread) also added valid points on the Sahara case. My concern here is,
> should we stick with DIB just because is the standard for image creation?
> Shouldn't we take in consideration that some projects, like Sahara, are
> moving away from it?
>
> - In the long term it would be ideal that we reach to a common solution
> for image creation for all the projects that need tailored images: Trove,
> Sahara, Octavia, Manila, and IIRC, Kolla and Cue.
>
> - In the short term, I'm on board or working on having tools based on DIB
> for image creation in Trove.
>
> - Amrith, Pete is working on the image creation process for Trove. The
> spec is up there [0]. I think is his work to kick-off that repository.
>
> *[amrith] The spec [0] referenced is entitled “Separate trove image build
> project based on libguestfs tools”. I am working on image building using
> the existing DIB elements that are already part of trove-integration. In
> any event, please see line 220 of [0] for a detailed explanation of why I
> am making the repository.*
>
>
>
> Best,
>
>
>
> Victoria
>
>
>
> [0] https://review.openstack.org/#/c/295274/
>
>
>
> 2016-05-04 23:20 GMT-03:00 Amrith Kumar :
>
> As we discussed at summit, (and consistent with all of the comments) we
> should move ahead with the project to advance the image builder for Trove
> and make it easier to build guest images for Trove by leveraging the DIB
> elements that we have in trove-integration.
>
>
>
> To that end, the infra [1] and governance [2] changes have been submitted
> for review. The Launchpad tracker [3] has been registered.
>
>
>
> I am working on taking the existing DIB elements in trove-integration and
> putting them in the new repository (openstack/trove-image-builder). I am
> also going to continue to watch this conversation and record any
> shortcomings with the existing DIB elements in Launchpad [3] and work on
> fixing those as well. Pete mentions one in his earlier email and I’ve
> logged that in Launchpad [4].
>
>
>
> Thanks,
>
>
>
> -amrith
>
>
>
> [1] https://review.openstack.org/#/c/312805/
>
> [2] https://review.openstack.org/#/c/312806/
>
> [3] https://launchpad.net/trove-image-builder
>
> [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454
>
>
>
>
>
>
>
> *From:* Mariam John [mailto:mari...@us.ibm.com]
> *Sent:* Wednesday, May 04, 2016 4:19 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
>
> *Subject:* Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
>
>
>
> The way I see this, these are the 2 main concerns I have been hearing
> regarding image building in Trove:
> 1) making the process simple and easy for users
> 2) addressing the issue of security
>
> I dont think there is any argument regarding the benefits of moving the
> database elements to a seperate repository and packaging and managing them
> from there.
>
> It looks like the case that we make for whether to use libguestfs or DIB
> for image building are in the technical details of how image building
> happens and their nuances - assuming that ease of use & having a simple
> interface to build secure images matters most, I wonder if the end-users
> would be concerned about these details.
>
> By addressing some of the issues like:
> - moving the Trove elements to a new repository
> - adding support for new distros
> - creating a wrapper script for building an image -getting the Trove guest
> agent code & configuration files
> - managing environment variables better
>
> I believe it will make a huge improvement in terms of simplifying and
> improving the ease of use for end users and hence could be the low hanging
> fruit that we can implement in the mean time. I agree that switching from
> DIB to any other tool is a big step and we need to put alot of thought into
> it like many 

Re: [openstack-dev] [tc] supporting Go

2016-05-05 Thread Hayes, Graham
On 04/05/2016 00:32, Hayes, Graham wrote:
> On 03/05/2016 17:03, John Dickinson wrote:
>> TC,
>>
>> In reference to 
>> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and 
>> Thierry's reply, I'm currently drafting a TC resolution to update 
>> http://governance.openstack.org/resolutions/20150901-programming-languages.html
>>  to include Go as a supported language in OpenStack projects.
>>
>> As a starting point, what would you like to see addressed in the document 
>> I'm drafting?
>>
>> --John
>>
>>
>>
>
> Great - I was about to write a thread like this :)
>
> Designate is looking to move a single component of ours to Go - and we
> were wondering what was the best way to do it.
>
> The current policy does allow for the TC to bless different languages
> on a case by case basis - do we need to go from just python and JS to
> allowing all projects to use go, or should the TC approve (or
> disapprove) the swift and designate requests?
>
> I think the swift and designate changes might be a good test case to
> see how the build / mirroring / packaging / artifact / library issues
> shake out.
>
> - Graham
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

So, as part of the update to that policy, should we have an
"OpenStack Go developer guide" that lays out how we think we will
implement go in our stack.

I am sure it will not be complete, or even correct for what we actually
do in the end, but it could give us a place to try and come to a shared
understanding.

I am thinking along the lines of:

  - For requirements we will use Godep and will use .gitignore to make
sure the vendored packages are not committed to git.

  - For inline code docs we will use Godoc, and for "narrative" docs,
we will use the OpenStack standard sphinx docs.

  - All go components will be functionally tested as part of a devstack
gate.

And many more I have probably forgotten.

Does this seem sane?

-- Graham

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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Amrith Kumar

From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com]
Sent: Thursday, May 05, 2016 9:00 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove

Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we should 
try to avoid changing tools unless highly necessary. The downsides we found for 
DIB are detailed in this spec [0] and Ethan (in this same thread) also added 
valid points on the Sahara case. My concern here is, should we stick with DIB 
just because is the standard for image creation? Shouldn't we take in 
consideration that some projects, like Sahara, are moving away from it?
- In the long term it would be ideal that we reach to a common solution for 
image creation for all the projects that need tailored images: Trove, Sahara, 
Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB for 
image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec is 
up there [0]. I think is his work to kick-off that repository.
[amrith] The spec [0] referenced is entitled “Separate trove image build 
project based on libguestfs tools”. I am working on image building using the 
existing DIB elements that are already part of trove-integration. In any event, 
please see line 220 of [0] for a detailed explanation of why I am making the 
repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar 
>:
As we discussed at summit, (and consistent with all of the comments) we should 
move ahead with the project to advance the image builder for Trove and make it 
easier to build guest images for Trove by leveraging the DIB elements that we 
have in trove-integration.

To that end, the infra [1] and governance [2] changes have been submitted for 
review. The Launchpad tracker [3] has been registered.

I am working on taking the existing DIB elements in trove-integration and 
putting them in the new repository (openstack/trove-image-builder). I am also 
going to continue to watch this conversation and record any shortcomings with 
the existing DIB elements in Launchpad [3] and work on fixing those as well. 
Pete mentions one in his earlier email and I’ve logged that in Launchpad [4].

Thanks,

-amrith

[1] https://review.openstack.org/#/c/312805/
[2] https://review.openstack.org/#/c/312806/
[3] https://launchpad.net/trove-image-builder
[4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454



From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Wednesday, May 04, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions) 
>

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove


The way I see this, these are the 2 main concerns I have been hearing regarding 
image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security

I dont think there is any argument regarding the benefits of moving the 
database elements to a seperate repository and packaging and managing them from 
there.

It looks like the case that we make for whether to use libguestfs or DIB for 
image building are in the technical details of how image building happens and 
their nuances - assuming that ease of use & having a simple interface to build 
secure images matters most, I wonder if the end-users would be concerned about 
these details.

By addressing some of the issues like:
- moving the Trove elements to a new repository
- adding support for new distros
- creating a wrapper script for building an image -getting the Trove guest 
agent code & configuration files
- managing environment variables better

I believe it will make a huge improvement in terms of simplifying and improving 
the ease of use for end users and hence could be the low hanging fruit that we 
can implement in the mean time. I agree that switching from DIB to any other 
tool is a big step and we need to put alot of thought into it like many others 
have suggested. Like Pete mentioned earlier in one of the links, there are 
couple of other tools available for building images. I am sure we could make 
the case for each of these tools and how it is easier/faster/better than the 
others. If we go down this route experimenting with libguestfs, is there 
anything stopping us couple of releases down the lane from wanting to 
experiment with some other tool because libguestfs doesn't perform well? The 
end user could use any tool they want to use to create images if they wish to 
do so but I agree and believe that Trove should support a standard way of 

Re: [openstack-dev] [nova][osc] Use of openstack client for admin commands

2016-05-05 Thread Murray, Paul (HP Cloud)


> -Original Message-
> From: Edward Leafe [mailto:e...@leafe.com]
> Sent: 05 May 2016 04:32
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [nova][osc] Use of openstack client for admin
> commands
> 
> On May 4, 2016, at 3:53 PM, Jay Pipes  wrote:
> 
> > My position is that if it's an HTTP API (as opposed to something like a
> sqlalchemy-migrate sync command) then it belongs in a client that speaks the
> OpenStack HTTP APIs. That is OSC as far as I can tell. I don't see a 
> difference
> between "admin" commands and "standard" commands.
> 
> Exactly. If it's an admin command and you're not an admin, you get an error.
> No need for a separate client.
> 

And more to the point, as far as I can tell it's only a statement in policy 
that determines which role can use the command. Any operator can change the 
policy and suddenly any division between clients becomes pure nonsense.


> 
> -- 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-dev] [Fuel] Meeting for May 5 Cancled

2016-05-05 Thread Andrew Woodward
Due to the empty agenda, and many people on holiday this week, We will
cancel today's meeting.

Meetings will resume on May 12 with their regularly scheduled programming
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Gregory Haynes

> 
> The approach being proposed by Pete is something that is equally
> applicable to DIB, I think. I believe that he makes a valid observation
> and our current element design may in fact be bad.
>  
> The invocation of DIB[1] is
> 
> ${PATH_DISKIMAGEBUILDER}/bin/disk-image-create -a amd64 -o "${VM}" \
> -x ${QEMU_IMG_OPTIONS} ${DISTRO} ${EXTRA_ELEMENTS} vm
> heat-cfntools \
> cloud-init-datasources ${DISTRO}-guest ${DISTRO}-${SERVICE_TYPE}
> 
> Observe that we include the ${DISTRO} element, and we prefix ${DISTRO}
> into the name of the guest and the database to get, for example,
> 
>   ... ubuntu ubuntu-guest ubuntu-mysql
> 
> The minimal set of bash and data files could be used instead and we won't
> have this matrix of datastore-by-distro proliferation that you speak of.
> That's why I believe that this solution is equally applicable to DIB.
> 
> [1] trove-integration/scripts/files/functions_qemu
> 

Ah, yep - the typical pattern for elements which are not distro elements
is to not make the distro part of the element name and then have the
element itself use the provided tools as much as possible to perform
tasks in a distro-agnostic fashion (see the package-installs element for
an example tool).

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


Re: [openstack-dev] [ironic] API docs now publishing from our tree

2016-05-05 Thread Jim Rollenhagen
On Wed, May 04, 2016 at 05:22:05PM -0400, Ruby Loo wrote:
> Sweet. Thanks Jim (and everyone else that made this happen).
> 
> I do want to make sure there is one "source of truth" to the API
> documentation. We are already generating REST API documentation at
> http://docs.openstack.org/developer/ironic/webapi/v1.html. The info for
> this comes from docstrings etc in our code files.
> 
> To make it easier and so that documentation doesn't get out of sync, I
> don't really want people to have to remember to update the code/docstrings
> as well as the new files that were added to generate this new api-ref
> documentation.

I agree. I think the first thing we need to do is get the api-ref tree
up to date. After that, we can refactor the stuff in doc/source/webapi
to be pointers to the new thing, and drop the API docs from the
docstrings.

Does that work for everyone?

// jim

> --ruby
> 
> 
> On Wed, May 4, 2016 at 5:10 PM, Jim Rollenhagen 
> wrote:
> 
> > Hey y'all,
> >
> > I did the push this week to move the api-ref into our tree, and it's now
> > publishing. \o/
> >
> > The docs are here: http://developer.openstack.org/api-ref/baremetal/
> >
> > The source is here:
> > http://git.openstack.org/cgit/openstack/ironic/tree/api-ref/source
> >
> > I know devananda is doing a push to update some things there. If you'd
> > like to help clean up and improve our docs, please sync with him. They
> > need a lot of love, so all help is welcome. :)
> >
> > // jim
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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


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


Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

2016-05-05 Thread Victoria Martínez de la Cruz
Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we
should try to avoid changing tools unless highly necessary. The downsides
we found for DIB are detailed in this spec [0] and Ethan (in this same
thread) also added valid points on the Sahara case. My concern here is,
should we stick with DIB just because is the standard for image creation?
Shouldn't we take in consideration that some projects, like Sahara, are
moving away from it?
- In the long term it would be ideal that we reach to a common solution for
image creation for all the projects that need tailored images: Trove,
Sahara, Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB
for image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec
is up there [0]. I think is his work to kick-off that repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar :

> As we discussed at summit, (and consistent with all of the comments) we
> should move ahead with the project to advance the image builder for Trove
> and make it easier to build guest images for Trove by leveraging the DIB
> elements that we have in trove-integration.
>
>
>
> To that end, the infra [1] and governance [2] changes have been submitted
> for review. The Launchpad tracker [3] has been registered.
>
>
>
> I am working on taking the existing DIB elements in trove-integration and
> putting them in the new repository (openstack/trove-image-builder). I am
> also going to continue to watch this conversation and record any
> shortcomings with the existing DIB elements in Launchpad [3] and work on
> fixing those as well. Pete mentions one in his earlier email and I’ve
> logged that in Launchpad [4].
>
>
>
> Thanks,
>
>
>
> -amrith
>
>
>
> [1] https://review.openstack.org/#/c/312805/
>
> [2] https://review.openstack.org/#/c/312806/
>
> [3] https://launchpad.net/trove-image-builder
>
> [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454
>
>
>
>
>
>
>
> *From:* Mariam John [mailto:mari...@us.ibm.com]
> *Sent:* Wednesday, May 04, 2016 4:19 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
> *Subject:* Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
>
>
>
> The way I see this, these are the 2 main concerns I have been hearing
> regarding image building in Trove:
> 1) making the process simple and easy for users
> 2) addressing the issue of security
>
> I dont think there is any argument regarding the benefits of moving the
> database elements to a seperate repository and packaging and managing them
> from there.
>
> It looks like the case that we make for whether to use libguestfs or DIB
> for image building are in the technical details of how image building
> happens and their nuances - assuming that ease of use & having a simple
> interface to build secure images matters most, I wonder if the end-users
> would be concerned about these details.
>
> By addressing some of the issues like:
> - moving the Trove elements to a new repository
> - adding support for new distros
> - creating a wrapper script for building an image -getting the Trove guest
> agent code & configuration files
> - managing environment variables better
>
> I believe it will make a huge improvement in terms of simplifying and
> improving the ease of use for end users and hence could be the low hanging
> fruit that we can implement in the mean time. I agree that switching from
> DIB to any other tool is a big step and we need to put alot of thought into
> it like many others have suggested. Like Pete mentioned earlier in one of
> the links, there are couple of other tools available for building images. I
> am sure we could make the case for each of these tools and how it is
> easier/faster/better than the others. If we go down this route
> experimenting with libguestfs, is there anything stopping us couple of
> releases down the lane from wanting to experiment with some other tool
> because libguestfs doesn't perform well? The end user could use any tool
> they want to use to create images if they wish to do so but I agree and
> believe that Trove should support a standard way of building images (DIB
> being an OpenStack project, I would assume that would be the standard) and
> do it well keeping it simple and easy to use as opposed to what it is
> today.
>
> I think we should split this into 2 tasks
> - one for going forward with seperating image building into a seperate
> repository and putting all efforts into simplifying the current process,
> and
> - second, to have a joint collaboration with the DIB/TripleO team to raise
> concerns regarding DIB and see if we can address them in turn OR if using a
> different tool like libguestfs makes sense at that point.
>
> Thanks,
> Mariam.
>

[openstack-dev] [tricircle] About the dynamic pod binding

2016-05-05 Thread Yipei Niu
Hi, all,

For dynamic pod binding, I have some questions.

1. Do we need to store historical pod binding records in the pod binding
table? Why?
2. How do we manage pod binding filters, store them in DB?
3. How is Tricircle aware of what type of resource wanted by tenants? For
example, a tenant wants to boot VMs for CAD modelling with corresponding
flavor. But in current code, the flavorRef is not get involved in function
get_pod_by_az_tenant, when querying pod bindings. So do we need to modify
the pod binding table to add such a column?

Best regards,
Yipei
__
OpenStack Development Mailing List (not for 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] Live Migration: Austin summit update

2016-05-05 Thread Timofei Durakov
We've tested live migration of instances under load for following features:
 - Auto-converge
 - XBZRLE compression
Tests were done against qemu 2.5. Instances had 2GB ram and stress tool was
used to emulate load:

$ stress -m 1 --vm-bytes 200M --vm-keep

None of them could be called silver-bullet for live-migration process.
Load mentioned above made live-migration process not that stable as
wanted.
I've also planned to tests all features that Daniel mentioned and it would
be intresting
to compare results.

Timofey.

On Wed, May 4, 2016 at 11:48 AM, Daniel P. Berrange 
wrote:

> On Tue, May 03, 2016 at 04:16:43PM -0600, Chris Friesen wrote:
> > On 05/03/2016 03:14 AM, Daniel P. Berrange wrote:
> >
> > >There are currently many options for live migration with QEMU that can
> > >assist in completion
> >
> > 
> >
> > >Given this I've spent the last week creating an automated test harness
> > >for QEMU upstream which triggers migration with an extreme guest CPU
> > >load and measures the performance impact of these features on the guest,
> > >and whether the migration actually completes.
> > >
> > >I hope to be able to publish the results of this investigation this week
> > >which should facilitate us in deciding which is best to use for
> OpenStack.
> > >The spoiler though is that all the options are pretty terrible, except
> for
> > >post-copy.
> >
> > Just to be clear, it's not really CPU load that's the issue though,
> right?
> >
> > Presumably it would be more accurate to say that the issue is the rate at
> > which unique memory pages are being dirtied and the total number of dirty
> > pages relative to your copy bandwidth.
> >
> > This probably doesn't change the results though...at a high enough dirty
> > rate you either pause the VM to keep it from dirtying more memory or you
> > post-copy migrate and dirty the memory on the destination.
>
> Yes that's correct - I should have been more explicit. A high rate of
> dirtying memory implies high CPU load, but high CPU load does not imply
> high rate of dirtying memory. My stress test used for benchmarking is
> producing a high rate of dirtying memory.
>
> 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] [kolla] better solution for the non-ini format configure file

2016-05-05 Thread Paul Bourke
TL;DR keep globals.yml to a minimum, customise configs via 
host_vars/group_vars


It seems right now the "best" approach may be to tokenise variables as 
required. This is the approach we currently use in Oracle. There are two 
other approaches I can think of available to us:


1) The overwrite mechanism as Jeffrey mentioned
2) Make the merge_configs script modular so it can handle more formats 
than just ini


The problem with 1) is that it is heavy weight for the Operator who 
wants to just customise one or two variables such as WEBROOT. Now they 
have to copy and maintain the entire config file.


The problem with 2) is that I feel it's a burden on us to write and 
maintain code that can merge many different file formats. It could be 
done, though may potentially be outside the scope of the project.


The tokenisation approach is unfortunately against what is described in 
"Kolla’s Deployment Philosophy"[0] though the reality may be that this 
approach is the most Operator friendly. In regards to concern of 
globals.yml growing unmanageable, I feel globals.yml is overused and 
should only store the bare minimum. Service specific variables should be 
kept within their own role files (e.g. ansible/roles/horizon/defaults), 
and then documented which are available for tweaking via top level 
host_vars/group_vars. This is standard practice in other Ansible roles 
I've come across.


-Paul

[0] http://docs.openstack.org/developer/kolla/deployment-philosophy.html

On 04/05/16 16:28, Mauricio Lima wrote:

I agree with your approach Jeffrey, although this is not ideal, this is
an approach already used in kolla.

2016-05-04 12:01 GMT-03:00 Jeffrey Zhang >:

Recently, Jack Ning pushed a PS[0], which export the `WEBROOT` to
the globals.yml file.
Because there is no chance to change the horizon/apache configure
file now.

The root cause is that: Kolla do not support non-ini format
configure file. for the
ini-format file, we use a merge_config module[1] to merge all the
found file. But it
will be not work for configure file for apache, rabbitmq and so on.

I would like to the current merge_config implementation. It is
directly and easy to use.
Not like the puppet, we have to remember the variable name defined
in the module. we have
no chance to add some user-defined variable.

Export the variable to global is very bad and ugly. It will became a
disaster when more
and more variables is exported.

So we should catch up a better solution to handle the configure file.

One solution I have is use overwrite mechanism. for example when
there is a file in
/etc/kolla/config/apache.conf, it will overwrite the templates in
the roles. But this
is still not ideal.

Any body has better solution?

[0] https://review.openstack.org/306928
[1]

http://git.openstack.org/cgit/openstack/kolla/tree/ansible/action_plugins/merge_configs.py

--
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] [Fuel][Plugins][SDK] How to create a plugin-specific Launchpad project

2016-05-05 Thread Irina Povolotskaya
Hi to everyone,

as the follow-up to my previous email [1],I'm providing the URLs to assist
with
plugin-specific LP project setup:

1) guidelines on how to make it happen [2]
2) list of already existing LP projects [3]

if you already have a project, please add it into the list to let everyone
know where to submit issues if any.

thanks.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-April/092712.html
[2]https://wiki.openstack.org/wiki/Fuel/Plugins#Launchpad_project
[3] https://wiki.openstack.org/wiki/Fuel/Plugins/Launchpad_projects_list

-- 
Best regards,

Irina Povolotskaya
__
OpenStack Development Mailing List (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] [mistral] Blueprints based on the Austin Summit discussions

2016-05-05 Thread Renat Akhmerov
Hi,

Here’s a list of new/revisited blueprints that reflect what we were able to 
discuss and decide at the summit:
https://blueprints.launchpad.net/mistral/+spec/event-notification-trigger 

https://blueprints.launchpad.net/mistral/+spec/mistral-multi-site-support 

https://blueprints.launchpad.net/mistral/+spec/mistral-embedded-mode 

https://blueprints.launchpad.net/mistral/+spec/mistral-throttling-on-tasks-and-workflows
 

https://blueprints.launchpad.net/mistral/+spec/mistral-preconditions 

https://blueprints.launchpad.net/mistral/+spec/history-of-workflow-executions 

https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-concurrency-property
 

https://blueprints.launchpad.net/mistral/+spec/mistral-task-delivery-model 

https://blueprints.launchpad.net/mistral/+spec/mistral-alternative-rpc 

https://blueprints.launchpad.net/mistral/+spec/mistral-custom-actions-api 

https://blueprints.launchpad.net/mistral/+spec/mistral-separate-openstack-actions
 

https://blueprints.launchpad.net/mistral/+spec/mistral-fail-transition-message 

https://blueprints.launchpad.net/mistral/+spec/mistral-custom-yaql-functions 


The etherpads for Mistral sessions:
https://etherpad.openstack.org/p/mistral-austin-summit-topics-2106 

https://etherpad.openstack.org/p/mistral-austin-summit-topics-2106-notes 



The whole list of blueprints currently assigned for Newton cycle: 
https://blueprints.launchpad.net/mistral/newton 

It is right now a little bit too challenging so the next step to prioritize 
them and assign to milestones and people so that we see what is feasible and 
what is not.

Please let me know if you see that something important that we discussed is 
missing. Also feel free to add more details if you have them.

Thanks

Renat Akhmerov
@Nokia

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


[openstack-dev] [Cinder] gate-cinder-tox-db-functional job faulires and non-voting jobs

2016-05-05 Thread Ivan Kolodyazhny
Hi team,

It's pretty sad to me, but it seems that nobody cares about non-voting jobs
:(. Cinder functional tests job is broken about 5 days [1] and I didn't see
any comments on it in the reviews. As decided at summit, we're going to
make this job voting. Stats from [1] proves that it's stable enough but was
broken by a new oslo.versionedobject release. Anyway, there is a fix [1]
for it.

IMO, we have to care about non-voting jobs too. If they are not stable
enough, they should be moved to experimental queue. We have to pay
attention on such non-voting jobs like functional tests, Cinder under
Apache, Rally, LIO target, etc while reviewing the patches. Usually, we
break these jobs because we ignore non-voting failures.



[1]
http://graphite.openstack.org/render/?width=586=308&_salt=1462445496.596=00%3A00_20160401=23%3A59_20160505=stats.zuul.pipeline.check.job.gate-cinder-tox-db-functional.FAILURE=stats.zuul.pipeline.check.job.gate-cinder-tox-db-functional.SUCCESS
[2] https://review.openstack.org/#/c/312875/

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing List (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][Kuryr] - Sub repositories

2016-05-05 Thread Gal Sagie
Hello all,

Following the summit discussions and after summit checking we decided its
better for us
to try a sub repositories model for Kuryr (better for packaging and
requirement/dependencies management).

We would like to create additional sub repositories under Kuryr and i was
wondering if the correct
process would be to just create different new projects following [1] and
then update
the governance repository for Kuryr (attaching all these projects as
deliverable of Kuryr).

Or is there a better/simpler method to do this?


Thanks
Gal.

[1] http://docs.openstack.org/infra/manual/creators.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [QA][RFC] Skip this week meeting

2016-05-05 Thread Ken'ichi Ohmichi
Hi Masayuki,

Sorry for late response.
That is nice because we had much conversation at the summit.
Next QA meeting is May 12th 1700UTC.
I put the agenda for the next meeting on
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_May_12th_2016_.281700_UTC.29
It is nice to add more topics on that if anyone have.

Thanks
Ken Ohmichi

---

2016-05-02 7:03 GMT-07:00 Masayuki Igawa :
> Hi QA guys,
>
> We have very few topic this week to discuss. So I think we should skip
> this week meeting.
> Any thoughts?
>
> Best Regards,
> -- Masayuki Igawa
>
> __
> OpenStack Development Mailing List (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] [heat][qa] devstack plugin

2016-05-05 Thread Ken'ichi Ohmichi
Hi dixiaoli

Thanks for raising your hand for this work.
I put your name on https://etherpad.openstack.org/p/newton-qa-newton-priorities

Thanks
---

2016-05-05 2:13 GMT-07:00 dixiaoli <13051592...@163.com>:
> Hi,  Ken Omichi
>
> Thanks for point out this.
> I would like to help to do the devstack plugin in heat if there is no one is
> doing it now.
>
>
>
> Thanks
> dixiaoli
>
>
>
>
>
>
> At 2016-04-30 05:30:02, "Ken'ichi Ohmichi"  wrote:
>>Hi Heat-team,
>>
>>Thanks for talking the topic of devstack plugin with us in Austin summit.
>>As you know, many projects have started to use devstack plugin in each
>>project repo.
>>and it is nice to use the plugin in heat also.
>>
>>A good sample is ironic one:
>>https://review.openstack.org/#/q/topic:ironic-devstack-plugin
>>The way is like:
>>1. (heat) Add devstack plugin by copying the code from devstack
>>2. (project-config) Switch to use devstack plugin
>>3. (devstack) Remove lib/heat, ...
>>
>>The related doc is
>> http://docs.openstack.org/developer/devstack/plugins.html
>>I am happy to get helps to move forward.
>>
>>Thanks
>>Ken Omichi
>>
>>__
>>OpenStack Development Mailing List (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] [oslo][mistral] Saga of process than ack and where can we go from here...

2016-05-05 Thread Dmitry Tantsur

On 05/03/2016 11:24 PM, Joshua Harlow wrote:

Howdy folks,

So I meet up with *some* of the mistral folks during friday last week at
the summit and I was wondering if we as a group can find a path to help
that project move forward in their desire to have some kind of process
than ack (vs the existing ack then process) in there usage of the
messaging layer.

I got to learn that the following exists in mistral (sad-face):

https://github.com/openstack/mistral/blob/master/mistral/engine/rpc.py#L38

And it got me thinking about how/if we can as a group possibly allow a
variant of https://review.openstack.org/#/c/229186/ to get worked on and
merged in and release so that the above 'hack' can be removed.


Hey, lemme weigh in from ironic-inspector PoV.

As you maybe remember, we also need a queue with possibility of both 
ways of ack'ing for our HA work. So something like this patch doesn't 
seem to help us at all. We'll probably have to cargo-cult the mistral 
approach.


Is it possible to have a manual ack feature? I.e. for the handler to 
choose when to ack.




I also would like to come to some kind of understanding that we also
(mistral folks would hopefully help here) would remove this kind of
change in the future as the longer term goal (of something like
https://review.openstack.org/#/c/260246/) would progress.

Thoughts from folks (mistral and oslo)?

Anyway we can create a solution that works in the short term (allowing
for that hack to be removed) and working toward the longer term goal?

-Josh

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



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


Re: [openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...

2016-05-05 Thread Dmitry Tantsur

On 05/04/2016 08:21 AM, Mehdi Abaakouk wrote:


Hi,


That said, I agree with Mehdi that *most* RPC calls throughout OpenStack,
not being idempotent, should not use process-then-ack.


That why I think we must not call this RPC. And the new API should be
clear the expected idempotent of the application callbacks.


Thoughts from folks (mistral and oslo)?


Also, I was not at the Summit, should I conclude the Tooz+taskflow
approach (that ensure the idempotent of the application within the
library API) have not been accepted by mistral folks ?



Taskflow is pretty opinionated about the whole application design. We 
can't use it in ironic-inspector, but we also need process-then-ack 
semantics for our HA work.


__
OpenStack Development Mailing List (not for 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][qa] devstack plugin

2016-05-05 Thread dixiaoli
Hi,  Ken Omichi

Thanks for point out this.
I would like to help to do the devstack plugin in heat if there is no one is 
doing it now.



Thanks
dixiaoli









At 2016-04-30 05:30:02, "Ken'ichi Ohmichi"  wrote:
>Hi Heat-team,
>
>Thanks for talking the topic of devstack plugin with us in Austin summit.
>As you know, many projects have started to use devstack plugin in each
>project repo.
>and it is nice to use the plugin in heat also.
>
>A good sample is ironic one:
>https://review.openstack.org/#/q/topic:ironic-devstack-plugin
>The way is like:
>1. (heat) Add devstack plugin by copying the code from devstack
>2. (project-config) Switch to use devstack plugin
>3. (devstack) Remove lib/heat, ...
>
>The related doc is http://docs.openstack.org/developer/devstack/plugins.html
>I am happy to get helps to move forward.
>
>Thanks
>Ken Omichi
>
>__
>OpenStack Development Mailing List (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][osc] Use of openstack client for admin commands

2016-05-05 Thread Ghe Rivero

On 04/05/16 22:53, Jay Pipes wrote:

On 05/04/2016 01:08 PM, Chris Dent wrote:


The plans for generic resource pools[1] include a suite of new
commands for creating and updating resource pools. In today's Nova
API meeting[2] and afterwards in #openstack-nova[3] we discussed two
issues:

* Since the placement API associated with resource pools is eventually
   going to be hoisted out of nova it will be developed in a decoupled
   fashion within the nova tree. It makes sense to also hoist the client
   libraries in the same fashion. The canonical plan for CLIs is to
   plug in to OSC.

* There's some confusion on whether commands that are destined for
   admins and services but not end users are "supposed" to be in OSC.

Since then the spec has been updated to reflect using OSC but the
question of whether this is in fact the right place for this style
of commands remains open. Not just for this situation, but
generally.

Is there an official word on this? If not, should we make one?


My position is that if it's an HTTP API (as opposed to something like 
a sqlalchemy-migrate sync command) then it belongs in a client that 
speaks the OpenStack HTTP APIs. That is OSC as far as I can tell. I 
don't see a difference between "admin" commands and "standard" commands.




There is a very blurry line between "admin" and "standard" commands in 
most of the cases. (In shade, is already split between operatorcloud.py 
and openstackcloud.py, and for any new capability to include, the first 
discussion, always, is where to put it) Splitting it, will only 
frustrate operators and users trying to remember which function is 
included in each command (and knowing Murphy's law, they will always 
choose the wrong one). So, please, just one command to rule them all.


Ghe Rivero


__
OpenStack Development Mailing List (not for 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] Nominate Major Hayden for core in openstack-ansible-security

2016-05-05 Thread Matt Thompson
Definitely a +1 from me.

--Matt


On Wed, May 4, 2016 at 9:18 PM, Kevin Carter 
wrote:

> +1 for me too.
>
>
> --
>
> Kevin Carter
> IRC: cloudnull
>
>
> 
> From: Matthew Thode 
> Sent: Tuesday, May 3, 2016 1:50 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [openstack-ansible] Nominate Major Hayden for
> core in openstack-ansible-security
>
> On 05/03/2016 01:47 PM, Truman, Travis wrote:
> > Major has made an incredible number of contributions of code and reviews
> > to the OpenStack-Ansible community. Given his role as the primary author
> > of the openstack-ansible-security project, I can think of no better
> > addition to the core reviewer team.
> >
> > Travis Truman
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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 because it still means something to me
>
> --
> -- Matthew Thode (prometheanfire)
>
>
> __
> OpenStack Development Mailing List (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] [vitrage] [congress] Vitrage-Congress Collaboration

2016-05-05 Thread Weyl, Alexey (Nokia - IL)
Hi to all Vitrage and Congress contributors,

We had a good introduction meeting in Austin and we (Vitrage) think that we can 
have a good collaboration between the projects.

Vitrage, as an Openstack Root Cause Analysis (RCA) Engine, builds a topology 
graph of all the entities in the system (physical, virtual and application) 
from different datasources. It thus can enrich Congress by providing more data 
about what is happening in the system. Additionally, the Vitrage RCA and deduce 
alarms & states mechanism can enhance the visibility of faults and how they 
inter-relate.  By using this information Congress could then execute different 
policies and perform more accurate actions.

Another good property of Vitrage is that it can receive data also from 
non-openstack sources, like Nagios, which monitor the physical resources, 
including Switches (which are not modeled today in OpenStack).

There are many ways in which Congress-Vitrage combination would be helpful. To 
take just one example: 
a. If a physical Switch is down, Vitrage can raise deduced alarms on the 
connected hosts and on the virtual machines affected by this change in switch 
state. 
b. Congress will then be notified by Vitrage about these alarms, which can set 
off Congress policies of migration. 
c. Furthermore, due to the RCA functionality, Congress will be aware that the 
Switch error is the source of the problem, and can determine the best place to 
create new instances of the VMs so that this  switch fault will not impact the 
new instances.

As you can see, for each fault, we can use Vitrage to link it to other faults, 
and create alarms to reflect them. This is all done via Vitrage Templates, so 
the system is configurable to the needs of the user. Thus many more cases such 
as the example above could be thought of.

To summarize, Vitrage can enrich Congress with the following four features:
a. RCA
b. Deduced alarms
c. Physical, virtual and application layers
d. Graph structure and topology of the system that defines the connections and 
relationships between all entities on which we can run quick graph algorithms 
to decide different actions to perform

If you can think of additional use cases that can be used here, please share ☺

For more data about Vitrage and its insights please take a look here:
https://wiki.openstack.org/wiki/Vitrage

Best Regards,
Alexey Weyl

__
OpenStack Development Mailing List (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] [glance] Austin summit summary: Rolling upgrades

2016-05-05 Thread Nikhil Komawar
Hello everyone,

Just wanted to send a brief summary of the discussions at the summit.
This list is not holistic however, it covers the relevant aspects that
various stakeholders need to be aware of.

  * The intent is that we want operators to be able to upgrade from one
Glance release to the next with minimal (ideally, zero) downtime.

  * Nova's been working on this, so there's a good example of how to
accomplish this. Also, the product working group has a cross-project
spec on this topic.

  * Glance DB is the one component that would require some sophisticated
logic to avoid the downtime. Other services are being handled by
upgrade & swap mechanism.

  * Some discussion was around relative comparison on what other
services are doing:In terms of performance there's simple schemain
Glance thoughcan have massive data.

  *
The different approaches today include: 

  *
oslo versioned objects

  *
neutron: expansion/contraction scheme; expand, lazy updates, force
contract after some time

  *
ironic: not using versioned objects, pinning the version

  *
cinder: split across multiple releases - add table, code can handle both

  * Besides these there was some discussion around best practices for
upgrades: The preferred upgrade scheme is first DB, then registry
and then API.

  * There were some research items: documenting the draining protocol
for Glance nodes handling uploads. Write up alternatives in the spec
based on findings what other projects are achieving; sign-ups
include mclaren for cinder, rosmaita for neutron, nikhil for nova.
More volunteers are welcome.

For more information please reach out to me on #openstack-glance, email,
reply here etc.

-- 

Thanks,
Nikhil


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