date:20150723

Re: [openstack-dev] [Fuel] Switching keystone to apache wsgi

2015-07-23 Thread Mike Scherbakov

Just to ensure that everyone knows - patch is merged. I hope that we will
see performance improvements, and looking for test results :)

On Thu, Jul 23, 2015 at 1:13 PM Aleksandr Didenko adide...@mirantis.com
wrote:

 Hi,

 guys, we're about to switch keystone to apache wsgi by merging [0]. Just
 wanted to make sure everyone is aware of this change.
 If you have any questions or concerns let's discuss them in this thread.

 Regards,
 Alex

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

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

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

2015-07-23 Thread Antoni Segura Puimedon

On Fri, Jul 24, 2015 at 12:02 AM, Mohammad Banikazemi m...@us.ibm.com wrote:
 Daneyon Hansen (danehans) daneh...@cisco.com wrote on 07/23/2015
 03:40:38 PM:

 From: Daneyon Hansen (danehans) daneh...@cisco.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org, Mohammad Banikazemi/Watson/
 IBM@IBMUS, Steven Dake (stdake) std...@cisco.com
 Cc: Eran Gampel eran.gam...@toganetworks.com, Irena Berezovsky
 ir...@midokura.com
 Date: 07/23/2015 03:45 PM
 Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing
 Dockers networking to Neutron

 From: Antoni Segura Puimedon toni+openstac...@midokura.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Thursday, July 23, 2015 at 11:16 AM
 To: Mohammad Banikazemi m...@us.ibm.com, Steven Dake (stdake) 
 std...@cisco.com
 Cc: Eran Gampel eran.gam...@toganetworks.com, OpenStack
 Development Mailing List (not for usage questions) openstack-
 d...@lists.openstack.org, Irena Berezovsky ir...@midokura.com
 Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing
 Dockers networking to Neutron

 Why is a separate OpenStack project needed to contribute to
 libnetwork? I would think the Neutron community would follow the
 libnetwork contrib guidelines and submit the code.

When I talked with the libnetwork people, my original goal being to make
a libnetwork in tree driver before libnetwork was announced at Docker Con,
it was made clear to me that third party network providers like weave,
calico and Kuryr should be plugins for the remote driver and strictly out
of tree.

 While there may be contributions to docker/libnetwork at some point, the
 project is not about contributing to libnetwork. For example, the Neutron
 driver itself won't be part of the docker or libnetwork tree.

It is for what I stated above and Mohammad comes to the same conclusion
as I did. The external providers must live apart from libnetwork and we must
work together with other external providers in the future to better or increase
the surface of the plugin interface as common usage patterns emerge and
are seen as valuable by a sizable part of the libnetwork community.

 Making other
 OpenStack and Neutron services available for use by containers may be a good
 reason  for having it under the OpenStack and Neutron umbrella but I think
 one can debate where a project fits best.

My reason for this is that Kuryr aims to bring all the power and flexibility
of the Neutron networking to Docker containers and I can't think of any
community more fit to do so than the Neutron community itself.

Neutron has a mature codebase that provides services that can be useful for
container users. Services that are not commonly not available to them via an
API as convenient and flexible as Neutron is. That is why I think that
it is not just
those users of Neutron that are now looking at Docker that will find
Kuryr to be a natural
match, but I also expect users starting to scale up and optimize their
growing container
deployments to find Kuryr (by its exposure of the Neutron goods) to bring
them an interesting set of tools for their larger and fine tuned container based
deployments.

 Best,

 Mohammad

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

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

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

2015-07-23 Thread Sergii Golovatiuk

+1

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

On Thu, Jul 23, 2015 at 11:48 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:

 +1

 On Thu, Jul 23, 2015 at 10:50 AM Evgeniy L e...@mirantis.com wrote:

 +1

 On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
 wrote:

 At the moment we have several core reviewers for the fuel-main project.

 Roman Vyalov is responsible for merging of infrastructure-related
 variables and for the lists of packages.
 I am responsible for merges in make system. And I have not so much time
 for digging into makefiles.

 Vladimir Kozhukalov is responsible for the makesystem for a long time.
 And now he works on reducing complexity of the system. I do not merge any
 single patch without his approval. It's time to give formal transfer of
 responsibility for the fuel-main to him. I nominate Vladimir to fuel-main
 core.

 Please reply with +1/-1.


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


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

 --
 Mike Scherbakov
 #mihgen

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


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

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

2015-07-23 Thread Vitaly Kramskikh

+1

2015-07-24 1:56 GMT+03:00 Sergey Vasilenko svasile...@mirantis.com:

 +1

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




-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Monasca] Monasca mid-cycle meetup

2015-07-23 Thread Hochmuth, Roland M

Hi Chandeep, There are no fees. It would be great if you could join us. Also, 
please feel free to add to the agenda topics that you would like to cover.

If you are traveling, I can advise on hotels.

Regards --Roland


From: Chandeep Khamba ckha...@cray.commailto:ckha...@cray.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, July 23, 2015 at 2:16 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Monasca] Monasca mid-cycle meetup

Hi,


Is the schedule for this meetup confirmed .
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

I would like to know if there is any fees involved to join in , or I could just 
come in .

Thanks
CHandeep

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

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature

2015-07-23 Thread Mike Scherbakov

Since we are in FF state already, I'd like to have urgent estimate from one
of fuel-library cores:
- holser
- alex_didenko
- aglarendil
- bogdando

aglarendil is on vacation though. Guys, please take a look at
https://review.openstack.org/#/c/196114/ - can we accept it as exception?
Seems to be good to go...

I still think that additional Ceilometer support should be moved to the
next release.

Thanks,

On Thu, Jul 23, 2015 at 1:56 PM Mike Scherbakov mscherba...@mirantis.com
wrote:

 Hi Andrian,
 this is High priority blueprint [1] for 7.0 timeframe. It seems we still
 didn't merge the main part [2], and need FF exception for additional stuff.

 The question is about quality. If we focus on enhancements, then we don't
 focus on bugs. Which whether means to deliver work with lower quality of
 slip the release.

 My opinion is rather don't give FF exception in this case, and don't have
 Ceilometer support for this new feature.

 [1] https://blueprints.launchpad.net/fuel/+spec/compute-vmware-role
 [2] https://review.openstack.org/#/c/196114/

 On Thu, Jul 23, 2015 at 1:39 PM Andrian Noga an...@mirantis.com wrote:

 Hi,

 The patch patch for fuel-library
 https://review.openstack.org/#/c/196114/  that implements
 'compute-vwmare' role (https://mirantis.jira.com/browse/PROD-627) requires
 additional work to do (ceilometer support.), but as far as I can see it
 doesn't affect any other parts of the product.

 We plan to implement it in 3 working days (2 for implementation, 1 day
 for writing system test and test runs), it should not be hard since we
 already support ceilometer compute agent deployment on controller nodes.

 We need 1 DevOps engineer and 1 QA engineer to be engaged for this work.

 So I think it's ok to accept this feature as an exception for feature
 freeze.

 Regards,
 Andrian Noga
 Project manager
 Partner Centric Engineering
 Mirantis, Inc

 Mob.phone: +38 (063) 966-21-24

 Email: an...@mirantis.com
 Skype: bigfoot_ua

 --
 Mike Scherbakov
 #mihgen

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

Re: [openstack-dev] [Monasca] Monasca mid-cycle meetup

2015-07-23 Thread Chandeep Khamba

Hi Roland,

I am still a newbie to Monasca  , but would like to hear and participate
in the agenda items we already have.
If I have something specific would definitely add it.

Thanks

On 7/23/15, 1:58 PM, Hochmuth, Roland M roland.hochm...@hp.com wrote:

Hi Chandeep, There are no fees. It would be great if you could join us.
Also, please feel free to add to the agenda topics that you would like to
cover.

If you are traveling, I can advise on hotels.

Regards --Roland


From: Chandeep Khamba ckha...@cray.commailto:ckha...@cray.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
g
Date: Thursday, July 23, 2015 at 2:16 PM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
g
Subject: [openstack-dev] [Monasca] Monasca mid-cycle meetup

Hi,


Is the schedule for this meetup confirmed .
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

I would like to know if there is any fees involved to join in , or I
could just come in .

Thanks
CHandeep

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


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

Re: [openstack-dev] [Fuel] Question about unique default hostname for node

2015-07-23 Thread Andrew Woodward

On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev fzhad...@mirantis.com wrote:

 Thanks for your answers.

 Let me clarify some points:

 Sure, we have to validate hostnames during node renaming. And sure we do
 it. This issue appears when we already have node with name 'node-X' and new
 node is created without providing custom name. I'll give you the example:

 1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
 with ID  4) ;
 2. He renames it in 'node-5' (this name is correct and unique. OK)
 3. He adds new node without providing custom hostname.
 New node gets ID = 5 (it's primary key and increments automatically)
 and default hostname 'node-5'. (Here we have a problem with uniqueness.)

 It will be strange if we refuse to create node with default name if
 somebody has renamed another node using this name.

 About nodes hostnames. Actually we can't refuse to use custom hostnames in
 format 'node-{#}' because it is one of the main use cases. So we need to
 find the solution which accepts such renaming.

How is this a main use case? This is exactly what we should not support. If
they want the node to have 'node-5' as it's hostname we need them to be
node.id = 5 (IE the node id in the DB is 5) They would not need custom node
naming in this case.


 2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Hi guys,

 @Sergii, it looks like you misunderstood something. `node-uuid` is not
 a general use case. It's only about conflicting nodes, and I'm sure
 everyone's going to change such a hostname in order to avoid
 confusion.

 @Andrew,

 a) Database refuses hostnames that break unique constraint, sot it'll
 work out-of-box.

 b) I like this idea. I think refusing `node-id` where `id` is not
 actually a node id is good idea. It solves our problem.

 Thanks,
 Igor

 On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
 sgolovat...@mirantis.com wrote:
  node-uuid is very terrible from UX perspective of view. Ask support
 people
  if they are comfortable to ssh such nodes or telling the name in phone
  conversation with customer. If we cannot validate FQDN of hostname I
 would
  slip this feature to next release where we can pay more attention to
  details.
 
  --
  Best regards,
  Sergii Golovatiuk,
  Skype #golserge
  IRC #holser
 
 
 __
  OpenStack Development Mailing List (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




 --
 Kind Regards,
 Fedor Zhadaev
 Junior Software Engineer, Mirantis Inc.
 Skype: zhadaevfm
 E-mail: fzhad...@mirantis.com
  __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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

[openstack-dev] [Monasca] Monasca mid-cycle meetup

2015-07-23 Thread Chandeep Khamba

Hi,


Is the schedule for this meetup confirmed .
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

I would like to know if there is any fees involved to join in , or I could just 
come in .

Thanks
CHandeep
__
OpenStack Development Mailing List (not for 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][L3] Representing a networks connected by routers

2015-07-23 Thread Carl Baldwin

On Thu, Jul 23, 2015 at 1:45 PM, Kevin Benton blak...@gmail.com wrote:
We ran in to this long ago.

 What are some other examples? We've be good about keeping the network L2
 only. Segments, VLAN transparency, and other properties of the network are
 all L2.

Another thing is that we create floating IPs from external networks,
not subnets.  The individual subnets on an external network aren't
important to the end user, it is the collections of subnets that makes
up the address pool for the external network.  The end user doesn't
care about anything about the L2 part of an external network.  They
want to connect externally with L3 through their routers.  But, we
don't have anything to represent that external L3 network so we have
them select a floating_network_id.  If we had something to represent
the L3 part of a network wouldn't it make more sense for the user to
select that?  We don't, so they can't.

A neutron subnet is locked to a cidr which is too limiting to be useful.

I want floating IPs to work on these routed networks.  The current
model dictates that it be a neutron network for this to happen.  I'm
not opposed to suggestions to improve the model, I actually started
sketching some out at the mid-cycle.  But, it is invasive and will be
extremely difficult and painful.  Possibly prohibitively so.  I guess
I thought there might be a way without the pain.

 The example you gave about needing the network to see the grouping of
 subnets isn't the network leaking into L3, it's subnets requiring an L2
 container. Networks don't depend on subnets, subnets depend on networks. I
 would rather look at making that dependency nullable and achieving your
 grouping another way (e.g. subnetpool).

Yes, subnets require a network but I still think it is more than that.

 The issue I have with the routed network it's using a network but it ignores
 any of the properties of the network model because they are L2. So now we
 have an API that stops making sense for one of the object types (e.g. what
 would vlan transparency or mtu do on a routed network?), which is something
 I don't want to see.

I don't disagree that we could have a better model.  It is not a good
thing to ignore those attributes of the network.  My position is just
that the L3 parts are already tangled up in there somehow.  We either
need to improve the model or accept it.  IOW, I don't think what I
proposed in adding L3 stuff to the network that wasn't already here.
It is just proposing to ignore the L2 stuff for a new kind of network.

Carl

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

Re: [openstack-dev] [Monasca] Monasca mid-cycle meetup

2015-07-23 Thread Hochmuth, Roland M

Hi Simon, Sorry, we don't have any information on our Wiki. Ceilosca leverages 
the Ceilometer data collection pipeline via a Ceilometer-Monasca Publisher and 
the Ceilometer API via a Ceilometer-Monasca Storage Driver and is completely 
compatible with the Ceilometer v2 API.

Regards --Roland


From: Simon Pasquier spasqu...@mirantis.commailto:spasqu...@mirantis.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, July 22, 2015 at 2:08 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Monasca] Monasca mid-cycle meetup

Hi,
I've had a quick look at the Etherpad which mentions Ceilosca. The name is 
quite intriguing but I didn't find any reference to it in the Monasca Wiki. 
Could you tell us a bit more about it? Does it mean that Monasca plans to 
expose an API that would be compatible with the Ceilometer API?
BR,
Simon

On Wed, Jul 22, 2015 at 8:08 PM, Hochmuth, Roland M 
roland.hochm...@hp.commailto:roland.hochm...@hp.com wrote:
The Monasca mid-cycle meet up will be held at the HP campus in Fort Collins, CO 
from August 5-6. Further details on the location, time and tentative agenda can 
be found at

https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

Regards --Roland

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


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

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

2015-07-23 Thread Sergey Vasilenko

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

Re: [openstack-dev] [TripleO] Moving instack upstream

2015-07-23 Thread James Slagle

On Thu, Jul 23, 2015 at 2:40 AM, Derek Higgins der...@redhat.com wrote:
 See below


 On 21/07/15 20:29, Derek Higgins wrote:

 Hi All,
 Something we discussed at the summit was to switch the focus of
 tripleo's deployment method to deploy using instack using images built
 with tripleo-puppet-elements. Up to now all the instack work has been
 done downstream of tripleo as part of rdo. Having parts of our
 deployment story outside of upstream gives us problems mainly because it
 becomes very difficult to CI what we expect deployers to use while we're
 developing the upstream parts.

 Essentially what I'm talking about here is pulling instack-undercloud
 upstream along with a few of its dependency projects (instack,
 tripleo-common, tuskar-ui-extras etc..) into tripleo and using them in
 our CI in place of devtest.

 Getting our CI working with instack is close to working but has taken
 longer then I expected because of various complications and distractions
 but I hope to have something over the next few days that we can use to
 replace devtest in CI, in a lot of ways this will start out by taking a
 step backwards but we should finish up in a better place where we will
 be developing (and running CI on) what we expect deployers to use.

 Once I have something that works I think it makes sense to drop the jobs
 undercloud-precise-nonha and overcloud-precise-nonha, while switching
 overcloud-f21-nonha to use instack, this has a few effects that need to
 be called out

 1. We will no longer be running CI on (and as a result not supporting)
 most of the the bash based elements
 2. We will no longer be running CI on (and as a result not supporting)
 ubuntu

 Should anybody come along in the future interested in either of these
 things (and prepared to put the time in) we can pick them back up again.
 In fact the move to puppet element based images should mean we can more
 easily add in extra distros in the future.

 3. While we find our feet we should remove all tripleo-ci jobs from non
 tripleo projects, once we're confident with it we can explore adding our
 jobs back into other projects again

 Nothing has changed yet, I order to check we're all on the same page
 this is high level details of how I see things should proceed so shout
 now if I got anything wrong or you disagree.


 Ok, I have a POC that has worked end to end in our CI environment[1], there
 are a *LOT* of workarounds in there so before we can merge it I need to
 clean up and remove some of those workarounds and todo that a few things
 need to move around, below is a list of what has to happen (as best I can
 tell)

 1) Pull in tripleo-heat-template spec changes to master delorean
 We had two patches in the tripleo-heat-template midstream packaging that
 havn't made it into the master packaging, these are
 https://review.gerrithub.io/241056 Package firstboot and extraconfig
 templates
 https://review.gerrithub.io/241057 Package environments and newtork
 directories

I've merged these 2 (the ones against the correct branch, not the ones
you abandoned :-) )


 2) Fixes for instack-undercloud (I didn't push these directly incase it
 effected people on old versions of puppet modules)
 https://github.com/rdo-management/instack-undercloud/pull/5

Can you submit this on gerrithub?:
https://review.gerrithub.io/#/q/project:rdo-management/instack-undercloud


 3) Add packaging for various repositories into openstack-packaging
 I've pulled the packaging for 5 repositories into
 https://github.com/openstack-packages
 https://github.com/openstack-packages/python-ironic-inspector-client
 https://github.com/openstack-packages/python-rdomanager-oscplugin
 https://github.com/openstack-packages/tuskar-ui-extras
 https://github.com/openstack-packages/ironic-discoverd
 https://github.com/openstack-packages/tripleo-common

 I havn't imported these into gerrithub (incase following discussion we need
 to delete them again) but assuming we're in agreement we should pull them
 into gerrithub)

 4) update rdoinfo
 https://github.com/redhat-openstack/rdoinfo/pull/69
 If everybody is happy with all above we should merge this, all of the
 packages needed will now be on the delorean master repository

 5) Move DELOREAN_REPO_URL in tripleo-ci to a new delorean repo that includes
 all of the new packages

 6) Take most of the workarounds out of this patch[1] and merge it

 7) Reorg the tripleo ci tests (essentially remove all of the bash element
 based tests).

3 - 7 sound good to me.


 8) Pull instack, instack-undercloud, python-rdomanager-oscplugin,
 triple-common, tuskar-ui-extras and maybe more into the upstream gerrit

+1, note that tripleo-common is already in gerrit/git.openstack.org
(http://git.openstack.org/cgit/openstack/tripleo-common)


 From here on the way to run the tripleo will be to follow the documentation
 in instack-undercloud, we should no longer be using devtest, this means
 we've lost the automation devtest gave us, so we will have to slowly

[openstack-dev] [Fuel] Switching keystone to apache wsgi

2015-07-23 Thread Aleksandr Didenko

Hi,

guys, we're about to switch keystone to apache wsgi by merging [0]. Just
wanted to make sure everyone is aware of this change.
If you have any questions or concerns let's discuss them in this thread.

Regards,
Alex

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

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Fabrizio Soppelsa


Hello Vladimir, from me -1.

We can discuss if enable fuelmenu=yes or not in grub, but I wouldn't get 
rid of it. I've never heard complaints against fuelmenu from users, and 
it's widely used for basic settings afterinstall.


If the users had to manually edit another configuration file, should 
they remember to run a validator tool over it every time after editing 
the file? Or do we add a futher layer that invokes $EDITOR and after 
:wq, some validator performs a check...? IMO that's poor UX, and why 
reimplement it, in fuelmenu there are already nice fixed choices and 
check commands that restricts potential human mistakes.


F.


On 07/23/2015 04:23 AM, Vladimir Kozhukalov wrote:

Dear colleagues,

What do you think of getting rid of fuelmenu and substituting it with 
thoroughly commented text file + some validation + vim? The major pro 
of this is that text file is easier to extend and edit. Many people 
prefer vim UX instead of wandering through the semi-graphical 
interface. And it is not so hard to implement syntax and logic 
checking for the text file.


Please give your opinions about this.

Vladimir Kozhukalov


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


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

[openstack-dev] [nova] nova unittests will be affected by mock 1.3

2015-07-23 Thread Robert Collins

I've released mock 1.3 which really correctly fixes the behaviour of
mock_open. Unfortunately there is a test in nova that is faulty (and
was faulty but silently so with 1.2).

 https://review.openstack.org/204222 fixes this up.

I had intended to let it land before releasing, but I forgot I had it
applied to my local tree when I ran the nova tests with mock 1.3.0
before releasing.

So the good news is, I know that patch fixes things.

The bad news is, I know its needed.

Sorry :(.

jroll verified that Ironic works with mock 1.3, so thats known good.

BTW - the reason for doing it now, is that I'm travelling in 24 hours,
and releasing it closer to then would be bad, and the Python 3.5
release is happening, and it needs to sync reasonably closely with
that. Rock and hard place.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [nova] nova unittests will be affected by mock 1.3

2015-07-23 Thread Sean Dague

On 07/23/2015 06:34 PM, Robert Collins wrote:
 I've released mock 1.3 which really correctly fixes the behaviour of
 mock_open. Unfortunately there is a test in nova that is faulty (and
 was faulty but silently so with 1.2).
 
  https://review.openstack.org/204222 fixes this up.
 
 I had intended to let it land before releasing, but I forgot I had it
 applied to my local tree when I ran the nova tests with mock 1.3.0
 before releasing.
 
 So the good news is, I know that patch fixes things.
 
 The bad news is, I know its needed.
 
 Sorry :(.
 
 jroll verified that Ironic works with mock 1.3, so thats known good.
 
 BTW - the reason for doing it now, is that I'm travelling in 24 hours,
 and releasing it closer to then would be bad, and the Python 3.5
 release is happening, and it needs to sync reasonably closely with
 that. Rock and hard place.

I just fast approved the patch given the circumstances (and the fact
that much of Nova core is either on a plane or drinking right now). It's
a small tweak on our unit tests, and hopefully frees you up to do the
release.

Thanks for the heads up on checking the Nova tests before the release,
and providing the fix to the unit tests.

-Sean

-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] [Monasca] Monasca mid-cycle meetup

2015-07-23 Thread Chandeep Khamba

Roland, 

Could you please specify the time of the meetup , I need to book my
Airtickes accordingly

On 7/23/15, 4:30 PM, Chandeep Khamba ckha...@cray.com wrote:

Hi Roland,

I am still a newbie to Monasca  , but would like to hear and participate
in the agenda items we already have.
If I have something specific would definitely add it.

Thanks

On 7/23/15, 1:58 PM, Hochmuth, Roland M roland.hochm...@hp.com wrote:

Hi Chandeep, There are no fees. It would be great if you could join us.
Also, please feel free to add to the agenda topics that you would like to
cover.

If you are traveling, I can advise on hotels.

Regards --Roland


From: Chandeep Khamba ckha...@cray.commailto:ckha...@cray.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.o
r
g
Date: Thursday, July 23, 2015 at 2:16 PM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.o
r
g
Subject: [openstack-dev] [Monasca] Monasca mid-cycle meetup

Hi,


Is the schedule for this meetup confirmed .
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

I would like to know if there is any fees involved to join in , or I
could just come in .

Thanks
CHandeep

_
_
OpenStack Development Mailing List (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][L3] Representing a networks connected by routers

2015-07-23 Thread Kevin Benton

 IOW, I don't think what I
proposed in adding L3 stuff to the network that wasn't already here.

The point I'm trying to make is that there isn't any L3 stuff on the
network itself. There are L3 things that depend on the network because an
L2 network carries them. But the routed network proposes something that
depends on a network that doesn't actually exist as an L2 network and it
doesn't depend on the network for L2 transit. The network makes no sense
other than as a grouping mechanism.

Even in the floating IP case, you allocate them from a network because the
network actually carries them. If you attach a VM to that network it can
arp for them and all because it is an L2 network.
On Jul 23, 2015 5:09 PM, Carl Baldwin c...@ecbaldwin.net wrote:

 On Thu, Jul 23, 2015 at 1:45 PM, Kevin Benton blak...@gmail.com wrote:
 We ran in to this long ago.
 
  What are some other examples? We've be good about keeping the network L2
  only. Segments, VLAN transparency, and other properties of the network
 are
  all L2.

 Another thing is that we create floating IPs from external networks,
 not subnets.  The individual subnets on an external network aren't
 important to the end user, it is the collections of subnets that makes
 up the address pool for the external network.  The end user doesn't
 care about anything about the L2 part of an external network.  They
 want to connect externally with L3 through their routers.  But, we
 don't have anything to represent that external L3 network so we have
 them select a floating_network_id.  If we had something to represent
 the L3 part of a network wouldn't it make more sense for the user to
 select that?  We don't, so they can't.

 A neutron subnet is locked to a cidr which is too limiting to be useful.

 I want floating IPs to work on these routed networks.  The current
 model dictates that it be a neutron network for this to happen.  I'm
 not opposed to suggestions to improve the model, I actually started
 sketching some out at the mid-cycle.  But, it is invasive and will be
 extremely difficult and painful.  Possibly prohibitively so.  I guess
 I thought there might be a way without the pain.

  The example you gave about needing the network to see the grouping of
  subnets isn't the network leaking into L3, it's subnets requiring an L2
  container. Networks don't depend on subnets, subnets depend on networks.
 I
  would rather look at making that dependency nullable and achieving your
  grouping another way (e.g. subnetpool).

 Yes, subnets require a network but I still think it is more than that.

  The issue I have with the routed network it's using a network but it
 ignores
  any of the properties of the network model because they are L2. So now we
  have an API that stops making sense for one of the object types (e.g.
 what
  would vlan transparency or mtu do on a routed network?), which is
 something
  I don't want to see.

 I don't disagree that we could have a better model.  It is not a good
 thing to ignore those attributes of the network.  My position is just
 that the L3 parts are already tangled up in there somehow.  We either
 need to improve the model or accept it.  IOW, I don't think what I
 proposed in adding L3 stuff to the network that wasn't already here.
 It is just proposing to ignore the L2 stuff for a new kind of network.

 Carl

 __
 OpenStack Development Mailing List (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.serialization] Security or convenience?

2015-07-23 Thread Davanum Srinivas

Angus,

yes, oslo.serialization should remain suitable for security-sensitive
purposes. i don't believe we use either of the features today and no
intention to add it the future.

-- dims

On Thu, Jul 23, 2015 at 12:56 AM, Angus Lees g...@inodes.org wrote:
 I'm working on a draft spec[1] for a new privilege separation mechanism
 (oslo.privsep) and one of the reviewers mentioned oslo.serialization.  Yay.

 My question is: From a quick glance over the current objects, it looks fine
 atm - but is the intention that this library remain suitable for
 security-sensitive purposes?

 I guess I'm mostly concerned about things like PyYaml's !!python/object
 feature or pickle's ability to serialise arbitrary objects - super useful in
 normal use, just not in a security context.

  - Gus

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

 __
 OpenStack Development Mailing 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] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Matthew Mosesohn

We had that before and had very poor validation. Removing fuelmenu
would make the experience quite manual and prone to errors.

This topic comes up once a year only from Fuel Python developers
because they rarely use it and no dev cycles have been invested in
improving it.

The actual Fuel deployers use it and appreciate its validation and
wish to extend it.

I'd like to hear more feedback.

On Thu, Jul 23, 2015 at 2:23 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
 Dear colleagues,

 What do you think of getting rid of fuelmenu and substituting it with
 thoroughly commented text file + some validation + vim? The major pro of
 this is that text file is easier to extend and edit. Many people prefer vim
 UX instead of wandering through the semi-graphical interface. And it is not
 so hard to implement syntax and logic checking for the text file.

 Please give your opinions about this.

 Vladimir Kozhukalov

 __
 OpenStack Development Mailing List (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] why do we gate tempest using q-vpn not q-l3?

2015-07-23 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

I've stumbled on this one. It turns out we gate neutron against
openstack installation that runs vpn-agent instead of l3-agent [1]. Is
it really what we want to do? I would expect that gate validates l3
agent as is, as is usually found on usual installations that do not
need vpn connections.

Or is it the neat way we make sure we don't break vpn-agent?

[1]:
https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/test-f
eatures.sh#n21

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVsN1RAAoJEC5aWaUY1u57eZ0IAI9oJIikbvD5dxGPoB7wm7mX
9OE583CAjn+hGUIMGa0kpVSBeDQmkQdp92ginFOo1lvXQZVT30OCOJau5YVoGE77
Nl1d9TX6xO8vDkBNT5A69vHfZGxjL620+HvOHjupTYimqWiilj6fu0oUge2DNtI7
do8TgL7SpDx31z9pF70zxqfHbARXq3HOb/AMfTz8jBRcnZmuvOQLt4Q/Xri6KFUw
uW8XaEZ+3xJYsaFsWna8YIEQY/R4TDqnyStGvRqzX9CGRDkzc/0gWalBSAkXewdQ
sOwN4MhhxJcWMXRVwPp+auvBOKQJ8Bq5uIR0WRIDhAaUtDNHstDefFnCBzmX8nc=
=kxs2
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Igor Kalnitsky

Hello,

Here's my 2 cents on it.

I think the effort we put to support fuelmenu doesn't worth it. I used
to deploy fuel too often in previous release, and I never used
features of fuelmenu? Why? Because I prefer to apply changes on
already deployed node. Moreover, I don't like that users are prompted
with fuelmenu by default. I want to deploy fuel automatically, without
any manual actions (though it's another topic).

I'm agree with Vladimir, vim + config files are enough, since Fuel is
not a product for housewives. It's a product for those who do not
hesitate to use Vim for soft configuration.

Thanks,
Igor



On Thu, Jul 23, 2015 at 2:27 PM, Matthew Mosesohn
mmoses...@mirantis.com wrote:
 We had that before and had very poor validation. Removing fuelmenu
 would make the experience quite manual and prone to errors.

 This topic comes up once a year only from Fuel Python developers
 because they rarely use it and no dev cycles have been invested in
 improving it.

 The actual Fuel deployers use it and appreciate its validation and
 wish to extend it.

 I'd like to hear more feedback.

 On Thu, Jul 23, 2015 at 2:23 PM, Vladimir Kozhukalov
 vkozhuka...@mirantis.com wrote:
 Dear colleagues,

 What do you think of getting rid of fuelmenu and substituting it with
 thoroughly commented text file + some validation + vim? The major pro of
 this is that text file is easier to extend and edit. Many people prefer vim
 UX instead of wandering through the semi-graphical interface. And it is not
 so hard to implement syntax and logic checking for the text file.

 Please give your opinions about this.

 Vladimir Kozhukalov

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


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

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

[openstack-dev] [Ironic] [Oslo] Question about Futurist executors (was: NoFreeConductorWorker going away with move to Futurist?)

2015-07-23 Thread Dmitry Tantsur


Jim,

I'm redirecting your question to oslo folks, as I'm afraid my answer can 
be wrong.


On 07/23/2015 01:55 PM, Jim Rollenhagen wrote:

On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote:

Hi all!

Currently _spawn_worker in the conductor manager raises
NoFreeConductorWorker if pool is already full. That's not very user friendly
(potential source of retries in client) and does not map well on common
async worker patterns.

My understanding is that it was done to prevent the conductor thread from
waiting on pool to become free. If this is true, we no longer need it after
switch to Futurist, as Futurist maintains internal queue for its green
executor, just like thread and process executors in stdlib do. Instead of
blocking the conductor the request will be queued, and a user won't have to
retry vague (and rare!) HTTP 503 error.

WDYT about me dropping this exception with move to Futurist?



I kind of like this, but with my operator hat on this is a bit scary.
Does Futurist just queue all requests indefinitely? Is it configurable?
Am I able to get any insight into the current state of that queue?


I believe answer is no, and the reason IIUC is that Futurist executors 
are modeled after stdlib executors, but I may be wrong.




Just indefinitely queueing up everything seems like it could end with a
system that's backlogged to death, with no way to determine if that's
actually the problem or not.

// jim

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




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

[openstack-dev] [Manila] Midcycle meetup next week

2015-07-23 Thread Ben Swartzlander

This is just a reminder that the Manila midcycle meetup is next week 
(July 29-30). Please add your name to the etherpad if you intend to 
join! If you have a topic to discuss it's not too late to suggest it.


https://etherpad.openstack.org/p/manila-liberty-midcycle-meetup

-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] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Matthew Mosesohn

How much effort are we spending? I'm not so sure it's a major development drain.

Since Fuel 6.0 dev cycle (Sept 2014) until now there have been 34
commits into Fuelmenu:
* New features/functionality: 12
* Bugfix: 15
* Other: 7 (version bumps, and commits without bug ID)

Across 3 releases, that's only ~11 commits per release. We've added
features like generating random passwords for services, warnings about
setting credentials apart from the default, adding a hook for CI for
testing custom manifests on Fuel Master, and duplicate IP address
checks.

These improved user experience. If you take it away and replace it
with a config file with basic validation, we will see users fail to
deploy due to things that Fuelmenu already checks easily. Imagine
you're an existing user of Fuel and suddenly you install the newest
version of Fuel and see a large configuration file which you have to
set by hand. Here's a relic of what users used to have to configure by
hand:
https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp

Am I alone in thinking it's not the best use of our development
resources to throw it away and replace it with a text file that is
edited by hand?

On Thu, Jul 23, 2015 at 3:33 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote:
Hello,

Here's my 2 cents on it.

I think the effort we put to support fuelmenu doesn't worth it. I used
to deploy fuel too often in previous release, and I never used
features of fuelmenu? Why? Because I prefer to apply changes on
already deployed node. Moreover, I don't like that users are prompted
with fuelmenu by default. I want to deploy fuel automatically, without
any manual actions (though it's another topic).

I'm agree with Vladimir, vim + config files are enough, since Fuel is
not a product for housewives. It's a product for those who do not
hesitate to use Vim for soft configuration.

Thanks,
Igor

On Thu, Jul 23, 2015 at 2:27 PM, Matthew Mosesohn
mmoses...@mirantis.com wrote:
We had that before and had very poor validation. Removing fuelmenu
would make the experience quite manual and prone to errors.

This topic comes up once a year only from Fuel Python developers
because they rarely use it and no dev cycles have been invested in
improving it.

The actual Fuel deployers use it and appreciate its validation and
wish to extend it.

I'd like to hear more feedback.

On Thu, Jul 23, 2015 at 2:23 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Dear colleagues,

What do you think of getting rid of fuelmenu and substituting it with
thoroughly commented text file + some validation + vim? The major pro of
this is that text file is easier to extend and edit. Many people prefer vim
UX instead of wandering through the semi-graphical interface. And it is not
so hard to implement syntax and logic checking for the text file.

Please give your opinions about this.

Vladimir Kozhukalov

__
OpenStack Development Mailing List (not for 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] why do we gate tempest using q-vpn not q-l3?

2015-07-23 Thread Assaf Muller

It's a remnant of pre-*aaS split times - We have to reexamine our
testing strategy post-split.

- Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Hi all,
 
 I've stumbled on this one. It turns out we gate neutron against
 openstack installation that runs vpn-agent instead of l3-agent [1]. Is
 it really what we want to do? I would expect that gate validates l3
 agent as is, as is usually found on usual installations that do not
 need vpn connections.
 
 Or is it the neat way we make sure we don't break vpn-agent?
 
 [1]:
 https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/test-f
 eatures.sh#n21
 
 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQEcBAEBCAAGBQJVsN1RAAoJEC5aWaUY1u57eZ0IAI9oJIikbvD5dxGPoB7wm7mX
 9OE583CAjn+hGUIMGa0kpVSBeDQmkQdp92ginFOo1lvXQZVT30OCOJau5YVoGE77
 Nl1d9TX6xO8vDkBNT5A69vHfZGxjL620+HvOHjupTYimqWiilj6fu0oUge2DNtI7
 do8TgL7SpDx31z9pF70zxqfHbARXq3HOb/AMfTz8jBRcnZmuvOQLt4Q/Xri6KFUw
 uW8XaEZ+3xJYsaFsWna8YIEQY/R4TDqnyStGvRqzX9CGRDkzc/0gWalBSAkXewdQ
 sOwN4MhhxJcWMXRVwPp+auvBOKQJ8Bq5uIR0WRIDhAaUtDNHstDefFnCBzmX8nc=
 =kxs2
 -END PGP SIGNATURE-
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

Re: [openstack-dev] [Congress] Need reviews of bp rpc-for-dse

2015-07-23 Thread Tim Hinrichs

Hi Yingxin,

+1 to joining the sprint.  If you can't make the mid-cycle sprint in
person, we're planning to have a remote option.  Keep in mind though that
it will be harder to engage with everyone if you're remote.

We'll review your spec and get you feedback, but the purpose of the sprint
(Aug 6-7) is to decide and hopefully build the next generation of
communication between the policy engines and the datasources.

Tim

On Thu, Jul 23, 2015 at 1:22 AM Masahito MUROI muroi.masah...@lab.ntt.co.jp
wrote:

 Hi Yingxin,

 I think moving Congress from dse to rpc is a good idea.

 Congress team will discuss its scalability in mid cycle sprint[1], [2].
 I guess using rpc is one of key item for congress to get the ability.
 Why don't you join the meetup?

 [1] https://wiki.openstack.org/wiki/Sprints/CongressLibertySprint
 [2]

 http://www.eventbrite.com/e/congress-liberty-midcycle-sprint-tickets-17654731778

 best regard,
 masa

 On 2015/07/23 16:07, Cheng, Yingxin wrote:
  Hi all,
 
 
  I have some thoughts about congress dse improvement after having read
 the code for several days.
 
  Please refer to bp/rpc-for-dse
 https://blueprints.launchpad.net/congress/+spec/rpc-for-dse, its idea is
 to implement RPC in deepsix. Congress can benefit from lower-coupling
 between dse services. And the steps towards oslo-messaging integration can
 be milder too.
 
  Eager to learn everything from Community. Anything wrong, please kindly
 point it out.
 
 
  Thank you
  Yingxin
 
 
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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


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

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

Re: [openstack-dev] [fuel][puppet] Module Sync for Murano and Sahara

2015-07-23 Thread Andrew Woodward

Denis,

Now that I have better understanding of the history of the commit, I
understand that this was the best way through. The Sahara and Murano team's
effort was invaluable in getting these fixed up and in a good state. I
apologize that I have raised this as an issue. I was very concerned with
the commits before knowing theses details, It was necessary to get the
clarification.

Let me clarify what I understand now was going on with them.

Sahara.
A )Fuel had a number of better parts of the fork. there where two commits
[1][2] proposed to puppet-sahara from Fuel that where not merged that
reflected the better side of Fuel's fork.
B) The Sahara sync commit [3] into fuel represented upstream puppet-sahara
C) The Adapt commit [4] contained the two commits listed prior in A, kilo
support, stuff we needed to ensure it worked in fuel and Noop tests.

[1] https://review.openstack.org/#/c/198744/
[2] https://review.openstack.org/#/c/192721/
[3] https://review.openstack.org/#/c/202045
[4] https://review.openstack.org/#/c/202195/

Murano
D) Fuel has effectively the only usable Murano module
E) The Adapt commit [5] represented
* a major over hall of the code quality to make it suitable to propose
upstream
* fixes necessary to support kilo
* cleanup for modular
* Noop tests

[5] https://review.openstack.org/#/c/203731/

With the improved clarity of what was going on, it made it much easier
understand what I was reviewing and I'm glad of the current state.

Here are my thoughts on what we can do better next time:
* The commit and CR messages where not sufficient to understand entirely
what was going on with the commits and how it was tested.
* Separate out some of the changes into a commit chain to reduce the scope
of each CR so that its easier to review.
* For large reviews like this, we should let more reviewers know whats
going on the ML early. These showed up on my radar late and of course, I
freaked out.

On Wed, Jul 22, 2015 at 6:51 AM Denis Egorenko degore...@mirantis.com
wrote:

Hi Andrew!

Sahara already merged. All CI tests were succeeded, also was built custom
iso [1] and ran bvt tests [2], which also were succeeded and we got +1 from
QA team.
For Murano we will do the same: resolve all comments, build custom iso,
run custom bvt and wait +1 from Fuel CI and QA team.

[1]
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_7.0_iso/562/

[2]
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/7.0.custom.ubuntu.bvt_2/131/

2015-07-22 0:41 GMT+03:00 Andrew Woodward xar...@gmail.com:

I was looped into reviewing the sync commits for Murano and Sahara. Both
are in terrible shape and risk feature freeze at this point.

We need feed back from the authors here. What is actually required for
Kilo support (if any)from the Murano and Sahara modules? What will happen
if these slip the release. What can you do to simplify the review scope.
The most we can reasonably review is 500 LOC in any short time (and that's
pushing it).

Synopsis:
murano [1] is -2, this can't be merged; there is a adapt commit with out
any sync commit. The only way we will accept the fork method is a sync from
upstream +adapt as documented in [2] also it's neigh impossible to review
something this large with out the separation.
-2 There is no upstream repo with content, so where did this even come
from? We are/where the authority for murano at present so I'm baffled as to
where this came from.

Possible way through: A) Split sync from adapt, hopefully the adapt is
small enough to to review. B)Make only changes necessary for kilo support.

Sahara [3][4]
This is a RED flah here, I'm not even sure to call it -1, -2 or something
entirely else. I had with Serg M, This is a sync of upstream, plus the code
on review from fuel that is not merged into puppet-sahara. I'm going to say
that our fork is in much better shape at this moment, and we should just
let it be. We shouldn't sync this until the upstream code is landed.

Possible way through: C) The two outstanding commits inside the adapt
commit need to be pulled out. They should be proposed right on top of the
sync commit and should apply cleanly. I would prefer to see them as
separate commits so they can be compared to the source more accurately.
This should bring the adapt to something that could be reviewed. D) propose
only the changes necessary to get kilo support.

[1] https://review.openstack.org/#/c/203731/
[2]
https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Adding_new_puppet_modules_to_fuel-library
[3] https://review.openstack.org/#/c/202045
[4] https://review.openstack.org/#/c/202195/
--

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

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

2015-07-23 Thread Andrey Danin

Hi, folks.

I understand it may be not a good time but I want to make a proposal
regarding this feature.
The feature may be extremely useful for plugin developers if these labels
would be serialized into astute.yaml. They may be used by plugin tasks to
do node-specific modifications. Let me provide some examples:
* For Xen integration we need to provide unique Xen Server credentials for
each Compute node. But with current architecture we don't have any
customizable per-node parameters.
* It may be possible to use special labels to override global values (i.e.
libvirt_type, thus implementing BP
https://blueprints.launchpad.net/fuel/+spec/auto-virt-type).
* Another case may be the fencing. A user may put IPMI credentials into
labels.
And there are more cases like that.

Despite the original spec doesn't have this idea I propose to implement
that. Moreover, I've already did it. Here are my two commits with a spec
update [0] and an implementation[1]. They are pretty simple.

[0] https://review.openstack.org/#/c/205105/
[1] https://review.openstack.org/#/c/205113/


Please grant FFE to this feature with my additions till tomorrow evening.

On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com
wrote:


 Mike, thanks for the important points you've provided.

 My main argument for this FFE is the following: we've already got a
 confirmation from SME for this patch. But also got some not critical
 comments at the last minute before we were going to merge it and have to
 handle it now. But it looks that these comments don't block the feature and
 we can fix it after merging a base patch.

 We tested the patch and it matches an acceptance criteria for the feature
 with some not critical known issues that already converted to launchpad
 tickets.

 I believe we can land it in master tomorrow with +1 from SME.

 BTW, I see no intersection in reviewers with this patch
 https://review.openstack.org/#/c/204321/.

 Thank you,
 Julia


 On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com
 wrote:

 -1
 My concerns are the following:

1. This feature is of a High priority, not Essential [1]
2. We already had to give exception for flexible networking CLI part
[2], as it is essential one. So basically that means we have a conflict of
focus for SMEs in the area.
3. Just by working on this, we don't spend time on bugs. Which
increases risk of delivering on time with expected level of quality

 +390, -35 LOC also scare me a little bit, it's not a tiny change.

 One of the possible workarounds can be, if we deliver this patch after
 HCF, and have an updated package of client. If someone want it in
 experimental mode, then the one could update client package and have this
 functionality.

 If you convince me though that it can be finished by end of the week with
 only code reviews from SMEs (and only after flexible networking part is
 done), only after it I can change my mind.

 [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes
 [2] https://review.openstack.org/#/c/204321/

 On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski 
 skalinow...@mirantis.com wrote:

 +1 for this FFE as it's important to have this functionality covered in
 CLI

 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Hi Julia,

 I'm ok with FF exception for CLI part. I don't think it can somehow
 decrease product quality, so as a core I'll help to land it.

 Thanks,
 Igor

 On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich
 jkirnos...@mirantis.com wrote:
  Team,
 
  I would like to request an exception from the Feature Freeze for CLI
 changes
  of working with custom node labels added to fuelclient (fuel2) [1].
 UI and
  Nailgun parts of the story are already merged [2].
 
  There CLI request is being actively reviewed, the base flow is
 accepted.
  There are minimal risks here since the changes added to fuel2 version.
 
  Please, respond if you have any questions or concerns related to this
  request.
 
  Thanks in advance,
  Julia
 
  [1] https://review.openstack.org/#/c/204524/
  [2] https://review.openstack.org/#/c/201472/
 
 
 __
  OpenStack Development Mailing List (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

Re: [openstack-dev] [Congress] Need reviews of bp rpc-for-dse

2015-07-23 Thread Cheng, Yingxin

OK, get it.

-Yingxin

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Thursday, July 23, 2015 11:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Need reviews of bp rpc-for-dse

Hi Yingxin,

We definitely want details for what you have in mind.  In case you haven't done 
this before, we write a 'spec' to explain the details.  Here's some info on how 
to do that.

https://wiki.openstack.org/wiki/Congress#How_To_Propose_a_New_Feature

Tim

On Thu, Jul 23, 2015 at 12:13 AM Cheng, Yingxin 
yingxin.ch...@intel.commailto:yingxin.ch...@intel.com wrote:
Hi all,

I have some thoughts about congress dse improvement after having read the code 
for several days.

Please refer to 
bp/rpc-for-dsehttps://blueprints.launchpad.net/congress/+spec/rpc-for-dse, 
its idea is to implement RPC in deepsix. Congress can benefit from 
lower-coupling between dse services. And the steps towards oslo-messaging 
integration can be milder too.

Eager to learn everything from Community. Anything wrong, please kindly point 
it out.

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

Re: [openstack-dev] [fuel][puppet] Module Sync for Murano and Sahara

2015-07-23 Thread Emilien Macchi

On Thu, Jul 23, 2015 at 8:40 PM, Andrew Woodward xar...@gmail.com wrote:

Denis,

Let me clarify what I understand now was going on with them.

[1] https://review.openstack.org/#/c/198744/
[2] https://review.openstack.org/#/c/192721/
[3] https://review.openstack.org/#/c/202045
[4] https://review.openstack.org/#/c/202195/

We will accept any patch that do not break backward compatibility for at
least one release.

If you consider to propose upstream, please follow this instructions to
bootstrap the basic code structure:
https://wiki.openstack.org/wiki/Puppet/New_module

That will help you to have a compliant module from start.

[5] https://review.openstack.org/#/c/203731/

With the improved clarity of what was going on, it made it much easier
understand what I was reviewing and I'm glad of the current state.

On Wed, Jul 22, 2015 at 6:51 AM Denis Egorenko degore...@mirantis.com
wrote:

Hi Andrew!

[1]
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_7.0_iso/562/

[2]
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/7.0.custom.ubuntu.bvt_2/131/

2015-07-22 0:41 GMT+03:00 Andrew Woodward xar...@gmail.com:

I was looped into reviewing the sync commits for Murano and Sahara. Both
are in terrible shape and risk feature freeze at this point.

Possible way through: A) Split sync from adapt, hopefully the adapt is
small enough to to review. B)Make only changes necessary for kilo support.

Sahara [3][4]
This is a RED flah here, I'm not even sure to call it -1, -2 or
something entirely else. I had with Serg M, This is a sync of upstream,
plus the code on review from fuel that is not merged into puppet-sahara.
I'm going to say that our fork is in much better shape at this moment, and
we should just let it be. We shouldn't sync this until the upstream code is
landed.

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

Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.

2015-07-23 Thread Zaro

Hello Tang,  Openstack slaves only have a single executor so what you are
probably seeing is due to using build slaves that have multiple executors.
There were a few bugs[1] that was fixed recently around these types of
deadlock issues.   The new gearman-plugin release[2] contains fixes for
those issues.  Also if you want to test the gearman-plugin with Jenkins
independently of zuul you can use the simple gearman-plugin-client[3] to
send jobs your gearman server to see if the jobs get built.

[1] https://issues.jenkins-ci.org/browse/JENKINS-28891 and
https://issues.jenkins-ci.org/browse/JENKINS-25867
[2]
http://repo.jenkins-ci.org/repo/org/jenkins-ci/plugins/gearman-plugin/0.1.2/
[3] https://github.com/zaro0508/gearman-plugin-client

-Khai

On Thu, Jul 23, 2015 at 9:13 PM, Tang Chen tangc...@cn.fujitsu.com wrote:


 On 07/24/2015 12:00 PM, Tang Chen wrote:


 On 07/24/2015 10:08 AM, Tang Chen wrote:


 On 07/23/2015 11:44 PM, Asselin, Ramy wrote:

 Are you running on 'master' nodes? I remember seeing an issue where
 with a recent version of Jenkins or a plugin where it doesn't execute jobs
 on the master node.
 But when run on non-master jenkins slaves, it works fine.


 I checked my configuration, and made sure these things:
 1. I have only a master node, no slave node.
 2. I have 20 idle executors on master node.
 3. My master node is online.
 4. My master node is set to Utilize this node as much as possible.
 5. zuul is able to be notified by Gerrit, and tell Jenkins to start jobs.

 But the jobs are always pending.


 And my Gearman reports this error sometimes.

 2015-07-25 10:50:44,914 ERROR gear.Server: Exception in poll loop:
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/dist-packages/gear/__init__.py, line
 2614, in _doPollLoop
 self._pollLoop()
   File /usr/local/lib/python2.7/dist-packages/gear/__init__.py, line
 2626, in _pollLoop
 ret = self.poll.poll()
 IOError: [Errno 4] Interrupted system call

 Not sure if it has anything to do with this problem.

 In Jenkins GUI, Gearman connection is tested successfully on
 127.0.0.1:4730.


 Seeing from zuul debug log, Gearman has successfully submitted the jobs.

 2015-07-25 11:42:09,255 DEBUG zuul.Scheduler: Adding trigger event:
 TriggerEvent patchset-created openstack-dev/sandbox master 205360,1
 2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Done adding trigger event:
 TriggerEvent patchset-created openstack-dev/sandbox master 205360,1
 2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Run handler awake
 2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Fetching trigger event
 2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Processing trigger event
 TriggerEvent patchset-created openstack-dev/sandbox master 205360,1
 2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager: Event
 TriggerEvent patchset-created openstack-dev/sandbox master 205360,1 for
 change Change 0x7ff518312c10 205360,1 matched EventFilter types:
 patchset-created in pipeline IndependentPipelineManager check
 2015-07-25 11:42:09,257 INFO zuul.Scheduler: Adding openstack-dev/sandbox,
 Change 0x7ff518312c10 205360,1 to Pipeline check
 2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager: Considering
 adding change Change 0x7ff518312c10 205360,1
 2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager: Checking
 for changes needed by Change 0x7ff518312c10 205360,1:
 2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager:   No
 changes needed
 2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager: Adding
 change Change 0x7ff518312c10 205360,1 to queue ChangeQueue check:
 openstack-dev/sandbox
 2015-07-25 11:42:09,258 DEBUG zuul.IndependentPipelineManager: Event
 TriggerEvent patchset-created openstack-dev/sandbox master 205360,1 for
 change Change 0x7ff518312c10 205360,1 matched EventFilter types:
 patchset-created in pipeline IndependentPipelineManager silent
 2015-07-25 11:42:09,258 INFO zuul.Scheduler: Adding openstack-dev/sandbox,
 Change 0x7ff518312c10 205360,1 to Pipeline silent
 2015-07-25 11:42:09,258 DEBUG zuul.IndependentPipelineManager: Considering
 adding change Change 0x7ff518312c10 205360,1
 2015-07-25 11:42:09,258 DEBUG zuul.IndependentPipelineManager: Unable to
 find change queue for change Change 0x7ff518312c10 205360,1 in project
 openstack-dev/sandbox
 2015-07-25 11:42:09,306 DEBUG zuul.IndependentPipelineManager: Starting
 queue processor: check
 2015-07-25 11:42:09,306 DEBUG zuul.IndependentPipelineManager: Checking
 for changes needed by Change 0x7ff518312c10 205360,1:
 2015-07-25 11:42:09,306 DEBUG zuul.IndependentPipelineManager:   No
 changes needed
 2015-07-25 11:42:09,306 DEBUG zuul.IndependentPipelineManager: Preparing
 ref for: Change 0x7ff518312c10 205360,1
 2015-07-25 11:42:09,307 INFO zuul.IndependentPipelineManager: Change
 Change 0x7ff518312c10 205360,1 depends on changes []
 2015-07-25 11:42:09,307 DEBUG zuul.MergeClient: Submitting job gear.Job
 0x7ff518325490 handle: None name: merger:merge

Re: [openstack-dev] [neutron][lbaasv2] Radware CI failure

2015-07-23 Thread Brandon Logan

?Evgeny/Sam/Radware,


https://os-ci-logs.radware.com/179818_27_2015-07-18_10-08-37/lbaas_v2_tempest_tests.log


The test_members module changed names.  Should be as easy as just renaming the 
import.  I'd also check for other module renames as well.


Thanks,

Brandon
__
OpenStack Development Mailing List (not for 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][L3] Representing a networks connected by routers

2015-07-23 Thread Paul Carver


On 7/23/2015 2:45 PM, Kevin Benton wrote:

We ran in to this long ago.


What are some other examples? We've be good about keeping the network L2
only. Segments, VLAN transparency, and other properties of the network are
all L2.

The example you gave about needing the network to see the grouping of
subnets isn't the network leaking into L3, it's subnets requiring an L2
container. Networks don't depend on subnets, subnets depend on networks. I
would rather look at making that dependency nullable and achieving your
grouping another way (e.g. subnetpool).



I think Kevin is right here. Network is fundamentally a layer 2 
construct, it represents direct reachability. A network could in 
principle support non-IP traffic (though in practice that may or may not 
work depending on underlying implementation.) Subnet is fundamentally a 
layer 3 construct it represents addressing for traffic that may need to 
flow between different networks (quite literally, that's where the name 
*inter*net protocol comes from.)


Because there is often a 1:1 relationship between network and subnet 
it's easy to blur the distinction, but I think it's worth keeping the 
concepts clear. An address scope or supernet (in the specific meaning of 
a summarized collection of subnets (e.g. a /23 made up of 8 /26s)) is a 
more accurate conceptual representation of multiple L2 segments with 
routing between them.




__
OpenStack Development Mailing List (not for 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] LDAP identity driver with groups from local DB

2015-07-23 Thread Steve Martinelli

The LDAP driver for identity shouldn't require write access to look up
groups. It'll only require write access if you want to allow Keystone to
create/delete/update new groups.
Not sure what you mean by requires an LDAP admin to set up groups
separately either. Have any more details you can share?

Thanks,

Steve Martinelli
OpenStack Keystone Core

Julian Edwards bigjo...@gmail.com wrote on 2015/07/24 12:00:33 AM:

 From: Julian Edwards bigjo...@gmail.com
 To: openstack-dev@lists.openstack.org
 Date: 2015/07/24 12:01 AM
 Subject: [openstack-dev] [keystone] LDAP identity driver with groups
 from local DB

 Hello,

 I am relatively new to Openstack and Keystone so please forgive me any
 crazy misunderstandings here.

 One of the problems with the existing LDAP Identity driver that I see
 is that for group management it needs write access to the LDAP server,
 or requires an LDAP admin to set up groups separately.

 Neither of these are palatable to some larger users with corporate
 LDAP directories, so I'm interested in discussing a solution that
 would get acceptance from core devs.

 My initial thoughts are to create a new driver that would store groups
 and their user memberships in the local keystone database, while
 continuing to rely on LDAP for user authentication. The advantages of
 this would be that the standard UI tools could continue to work for
 group manipulation.  This is somewhat parallel with ephemeral
 federated user group mappings, but that's all done in the json blob
 which is a bit horrible. (I'd like to see that working with a decent
 UI some time, perhaps it is solved in the same way)

 However, one of the other reasons I'm sending this is to gather more
 ideas to solve this. I'd like to hear from anyone in a similar
 position, and anyone with input on how to help.

 Cheers,
 Julian.


__
 OpenStack Development Mailing List (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] [keystone] LDAP identity driver with groups from local DB

2015-07-23 Thread Matt Fischer

Julian,

You want this hybrid backend driver. Bind against LDAP for auth, store
everything else in mysql:

https://github.com/SUSE-Cloud/keystone-hybrid-backend

We maintain our own fork with has a few small differences. I do not use the
assignment portion of the driver and I'm not sure anyone does so keep that
in mind.

I know some of the Keystone team has pretty strong opinions about this but
it works for us.

And nice to run into you again...

On Thu, Jul 23, 2015 at 10:00 PM, Julian Edwards bigjo...@gmail.com wrote:

 Hello,

 I am relatively new to Openstack and Keystone so please forgive me any
 crazy misunderstandings here.

 One of the problems with the existing LDAP Identity driver that I see
 is that for group management it needs write access to the LDAP server,
 or requires an LDAP admin to set up groups separately.

 Neither of these are palatable to some larger users with corporate
 LDAP directories, so I'm interested in discussing a solution that
 would get acceptance from core devs.

 My initial thoughts are to create a new driver that would store groups
 and their user memberships in the local keystone database, while
 continuing to rely on LDAP for user authentication. The advantages of
 this would be that the standard UI tools could continue to work for
 group manipulation.  This is somewhat parallel with ephemeral
 federated user group mappings, but that's all done in the json blob
 which is a bit horrible. (I'd like to see that working with a decent
 UI some time, perhaps it is solved in the same way)

 However, one of the other reasons I'm sending this is to gather more
 ideas to solve this. I'd like to hear from anyone in a similar
 position, and anyone with input on how to help.

 Cheers,
 Julian.

 __
 OpenStack Development Mailing List (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] What's Up, Doc? 24 July 2015

2015-07-23 Thread Lana Brindley

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

Wow! What a great week for RST conversion patches! As I write this,
there are only a handful of outstanding sections on the Cloud Admin and
HA Guides, and well over 40 sections have now been converted on the
Install Guide, with the conversion sprint running for another twelve
hours or so. Thank you to everyone who has taken the time to grab a
section and do a conversion, and to all those people who have given
their +1 to a patch. I can't wait to see all our shiny new books up on
docs.openstack.org :)

== Progress towards Liberty ==

* RST conversion:
** Install Guide: Conversion is now underway, sign up here:
https://wiki.openstack.org/wiki/Documentation/Migrate#Installation_Guide_Migration
** Cloud Admin Guide: is nearly done. Sign up here:
https://wiki.openstack.org/wiki/Documentation/Migrate#Cloud_Admin_Guide_Migration
** HA Guide: is also nearly done. Get in touch with Meg or Matt:
https://wiki.openstack.org/wiki/Documentation/HA_Guide_Update
** Security Guide: Conversion is now underway, sign up here:
https://etherpad.openstack.org/p/sec-guide-rst

* User Guides information architecture overhaul
** Waiting on the RST conversion of the Cloud Admin Guide to be complete

* Greater focus on helping out devs with docs in their repo
** Work has stalled on the Ironic docs, we need to pick this up again.
Contact me if you want to know more, or are willing to help out.

* Improve how we communicate with and support our corporate contributors
** I have been brainstorming ideas with Foundation, watch this space!

* Improve communication with Docs Liaisons
** I'm very pleased to see liaisons getting more involved in our bugs
and reviews. Keep up the good work!

* Clearing out old bugs
** Sadly, no progress on the spotlight bugs from last week. I'll hold
them over for another week, so now is your chance to jump in  and grab them!

== RST Migration ==

The next books we are focusing on for RST conversion are the Install
Guide, Cloud Admin Guide, HA Guide, and the Security Guide. If you would
like to assist, please get in touch with the appropriate speciality team:

* Install Guide:
** Contact Karin Levenstein karin.levenst...@rackspace.com
** Sign up here:
https://wiki.openstack.org/wiki/Documentation/Migrate#Installation_Guide_Migration
** The sprint on this book has been a major success, and there's still
about twelve hours left until it wraps up at 1500 UTC (24 July). Info
and sign up here:
https://wiki.openstack.org/wiki/VirtualSprints#Installation_guide_conversion_from_DocBook_to_RST

* Cloud Admin Guide:
** Contact Brian Moss kallimac...@gmail.com  Joseph Robinson
joseph.r.em...@gmail.com
** Sign up to help out here:
https://wiki.openstack.org/wiki/Documentation/Migrate#Cloud_Admin_Guide_Migration

* HA Guide
** Contact Meg McRoberts dreidellh...@yahoo.com or Matt Griffin
m...@mattgriffin.com
** Blueprint:
https://blueprints.launchpad.net/openstack-manuals/+spec/improve-ha-guide

* Security Guide
** Contact Nathaniel Dillon nathaniel.dil...@hp.com
** Info: https://etherpad.openstack.org/p/sec-guide-rst

For books that are now being converted, don't forget that any change you
make to the XML must also be made to the RST version until conversion is
complete. Our lovely team of cores will be keeping an eye out to make
sure loose changes to XML don't pass the gate, but try to help them out
by pointing out both patches in your reviews.

== HA Guide Works ==

With the RST conversion on the HA Guide wrapping up, the HA Guide
speciality team are looking for people to help out with the
reorganisation and writing the new content. They have quite a few bugs
to get through, and they need your help! Contact Matt Griffin, or any
other member of the HA Guide Speciality Team, or join their weekly IRC
meeting. Details here:
https://wiki.openstack.org/wiki/Documentation/HA_Guide_Update

== Docs Tools ==

While they're not strictly docs tools, I wanted to mention review
dashboards here today. Did you know that we maintain a list of custom
OpenStack review dashboards for you to use? They're customised to show
only the reviews you care about, which can save you a lot of time and
needless clicking. All you need to do is pick the dashboard you want to
use, copy the URL, and save it to your bookmarks. Anne has just updated
the Docs Review Inbox dashboard to include DocImpact reviews, so it's
worth checking out:
http://ghostcloud.net/openstack_gerrit_dashboards/dashboard_doc-program.html
You can see the full list here:
http://ghostcloud.net/openstack_gerrit_dashboards/

== APAC Docs Swarm ==

The APAC team have been working on holding another doc swarm, this time
working on the Architecture Design Guide. It's to be held at the Red Hat
office in Brisbane, on 13-14 August. Check out
http://openstack-swarm.rhcloud.com/ for all the info.

== Doc team meeting ==

The APAC docs meeting was held this week, catch up on the minutes here:

[openstack-dev] [keystone] LDAP identity driver with groups from local DB

2015-07-23 Thread Julian Edwards

Hello,

I am relatively new to Openstack and Keystone so please forgive me any
crazy misunderstandings here.

One of the problems with the existing LDAP Identity driver that I see
is that for group management it needs write access to the LDAP server,
or requires an LDAP admin to set up groups separately.

Neither of these are palatable to some larger users with corporate
LDAP directories, so I'm interested in discussing a solution that
would get acceptance from core devs.

My initial thoughts are to create a new driver that would store groups
and their user memberships in the local keystone database, while
continuing to rely on LDAP for user authentication. The advantages of
this would be that the standard UI tools could continue to work for
group manipulation.  This is somewhat parallel with ephemeral
federated user group mappings, but that's all done in the json blob
which is a bit horrible. (I'd like to see that working with a decent
UI some time, perhaps it is solved in the same way)

However, one of the other reasons I'm sending this is to gather more
ideas to solve this. I'd like to hear from anyone in a similar
position, and anyone with input on how to help.

Cheers,
Julian.

__
OpenStack Development Mailing List (not for 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][v2.1 api calls]

2015-07-23 Thread Sajeesh Cimson Sasi

Thanks Ed for the explanation
  what is the meaning of contained support. api calls, for example  
GET /v2.1/os-quota-sets/{tenant_id}} was not working.
But /v3/os-quota-sets/{tenant_id}  was working fine
  whether I am missing something ?
   best regards
 sajeesh
   

From: Ed Leafe [e...@leafe.com]
Sent: 24 July 2015 07:56:03
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][v2.1 api calls]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/23/2015 09:16 PM, Sajeesh Cimson Sasi wrote:

 Can you please tell me whether nova supports v2.1 api calls now. If
 so can you please tell me where the code is located.I can see the
 codes for v2(quotas.py) and v3(plugin/v3/quots_sets.py). I was
 thinking that  v2.1 is equivalent to v3 calls, since the api calls
 are looking similar.

Yes, the Kilo release contained support for the v2.1 API, as well as
the support for microversions for future changes. The code is still in
the v3 directory; this is a holdover from the original attempt to
create a new v3 API that would be backwards-incompatible, which was
later abandoned in favor of the microversion approach.

There is a current effort to clean up the code base by removing the
old 'v3' references since, as you have learned, the current layout is
confusing.

- --

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVsaI7AAoJEKMgtcocwZqLa5AP/0OAE/fJYupvNmvUvx0adna6
F6g7k24PTkerXufbLOXe1PDkihDXbJifpGJZQB2sgx9zz1AHppC6Hj+TV+8TyjJP
cnIQtAYhffEKUcFOpYrY/fYWTNJ7L6a510R2Ly1K8OWGlDcYrCNz+VCIjOiyxeXT
I+CrDRReeprQC3UsJT8NlJrX2rV3tWFk+G3NCHFUDxd9DTwn3N+XrPgkU7BvRB+R
eszGev95AcwCN13b3Wj8MxPvGvcaJVoY5X3/CMluiXfuVlLa37cxJJetwZPyJV+h
lTzhKnSsjWnp/UOd6TtOhXqrRA+cg+XraAAYxi79/EUvXpx0UQFtDZNGLMi21W53
viBG6zgIr8spxTGN3BCVvbv4wBkF8qaCH8w0cAqqwqqRofCfCXaf8M9ayLxVBbgN
21DgbvNr+9WrHfKcA+vd97lhWjJMqhZH/C90QdNRPNkkcoKULdNK559hEX8YkbkY
algWuamd16SbinoeTkW9BRi3NKuaJoP48aBh8xAIy26HVGFMDVG/eBDlIMvL3Gp+
rNjDT9YOahVb4OdTB51Mw89nki7RSTpUuqFZ+TY3SuBfXdfR8X36aYhrJpIDy5nY
G7LjIx+hFKx+EwUnC01qjl30IcDPLnnGsVyZus3L6xEtSSLcQByQ/5MSSCv7wQ9a
UVG0zz0akMVDEoz+LPiZ
=1Fu4
-END PGP SIGNATURE-

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

Re: [openstack-dev] [fuel][puppet] Module Sync for Murano and Sahara

2015-07-23 Thread Emilien Macchi

On Wed, Jul 22, 2015 at 9:48 AM, Denis Egorenko degore...@mirantis.com
wrote:

Hi Andrew!

[1]
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_7.0_iso/562/

Private URL, we can't read the logs from Internet.

[2]
http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/7.0.custom.ubuntu.bvt_2/131/

Same here.

2015-07-22 0:41 GMT+03:00 Andrew Woodward xar...@gmail.com:

I was looped into reviewing the sync commits for Murano and Sahara. Both
are in terrible shape and risk feature freeze at this point.

Possible way through: A) Split sync from adapt, hopefully the adapt is
small enough to to review. B)Make only changes necessary for kilo support.

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

--
Best Regards,
Egorenko Denis,
Deployment Engineer
Mirantis

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

Re: [openstack-dev] [glance][api] Response when a illegal body is sent

2015-07-23 Thread michael mccune


On 07/23/2015 12:43 PM, Ryan Brown wrote:

On 07/23/2015 12:13 PM, Jay Pipes wrote:

On 07/23/2015 10:53 AM, Bunting, Niall wrote:

Hi,

Currently when a body is passed to an API operation that explicitly
does not allow bodies Glance throws a 500.

Such as in this bug report:
https://bugs.launchpad.net/glance/+bug/1475647 This is an example of
a GET however this also applies to other requests.

What should Glance do rather than throwing a 500, should it return a
400 as the user provided an illegal body


Yep, this.


+1, this should be a 400. It would also be acceptable (though less
preferable) to ignore any body on GET requests and execute the request
as normal.


Best,
-jay


i'm also +1 on the 400 band wagon

mike

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

Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.

2015-07-23 Thread Tang Chen



On 07/23/2015 11:44 PM, Asselin, Ramy wrote:

Are you running on 'master' nodes? I remember seeing an issue where with a 
recent version of Jenkins or a plugin where it doesn't execute jobs on the 
master node.
But when run on non-master jenkins slaves, it works fine.


I checked my configuration, and made sure these things:
1. I have only a master node, no slave node.
2. I have 20 idle executors on master node.
3. My master node is online.
4. My master node is set to Utilize this node as much as possible.
5. zuul is able to be notified by Gerrit, and tell Jenkins to start jobs.

But the jobs are always pending.

I'm now trying to setup a slave node and try again. :)

And anyone has any idea of this, please let me know.

Thanks.


-Original Message-
From: Tang Chen [mailto:tangc...@cn.fujitsu.com]
Sent: Thursday, July 23, 2015 12:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up 
a new CI system.

Hi, all

The Jenkins jobs submitted by zuul are always pending-Waiting for next available 
executor .

And Jenkins log shows the following:

Jul 24, 2015 11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl
submitFunction
WARNING:  Worker _exec-0 exception while executing function 
hudson.plugins.gearman.StartJobWorker
java.lang.RuntimeException: java.lang.RuntimeException:
java.util.concurrent.CancellationException
at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:136)
at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:22)
at
hudson.plugins.gearman.MyGearmanWorkerImpl.submitFunction(MyGearmanWorkerImpl.java:590)
at
hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:374)
at
hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException:
java.util.concurrent.CancellationException
at
hudson.plugins.gearman.StartJobWorker.executeFunction(StartJobWorker.java:116)
at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:125)
... 5 more
Caused by: java.util.concurrent.CancellationException
at hudson.remoting.AsyncFutureImpl.get(AsyncFutureImpl.java:77)
at
hudson.plugins.gearman.StartJobWorker.safeExecuteFunction(StartJobWorker.java:196)
at
hudson.plugins.gearman.StartJobWorker.executeFunction(StartJobWorker.java:114)
... 6 more

Jul 24, 2015 11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl work
INFO:  Worker _exec-0 sending initial grab job Jul 24, 2015 11:09:04 AM 
hudson.plugins.gearman.MyGearmanWorkerImpl
handleSessionEvent
INFO:  Worker _exec-1 received unique job assignment Jul 24, 2015 11:09:04 
AM hudson.plugins.gearman.MyGearmanWorkerImpl work
INFO:  Worker _exec-1 executing function Jul 24, 2015 11:09:04 AM 
hudson.plugins.gearman.StartJobWorker
safeExecuteFunction
INFO:  Worker _exec-1 scheduling devstack-vm-test build #14 on with UUID 
83d4fd10c1ad4f1ead51beb2adf23ccd and build params
[(StringParameterValue) BASE_LOG_PATH='03/204803/1',
(StringParameterValue) ZUUL_PIPELINE='check', (StringParameterValue) 
ZUUL_UUID='83d4fd10c1ad4f1ead51beb2adf23ccd', (StringParameterValue) 
LOG_PATH='03/204803/1/check/devstack-vm-test/83d4fd1',
(StringParameterValue) ZUUL_CHANGE_IDS='204803,1',
(StringParameterValue) ZUUL_PATCHSET='1', (StringParameterValue) 
ZUUL_BRANCH='master', (StringParameterValue) 
ZUUL_REF='refs/zuul/master/Z07d022076a68448d842bd1a47dd42e19',
(StringParameterValue)
ZUUL_COMMIT='174cac545549f086e07f32edbe34b70c4155a7fc',
(StringParameterValue) ZUUL_URL='http://10.124.196.205/p/',
(StringParameterValue) ZUUL_CHANGE='204803', (StringParameterValue) 
ZUUL_CHANGES='openstack-dev/sandbox:master:refs/changes/03/204803/1',
(StringParameterValue) ZUUL_PROJECT='openstack-dev/sandbox']


It seems that Gearman doesn't work properly.

Do you guys have any idea of this ?

Thanks.

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

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




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

[openstack-dev] [Nova] Cancel Nova API meeting this week

2015-07-23 Thread Xu, Hejie

Hi

As people join mid-cycle meetup, we cancel nova API meeting this week.

Thanks
Alex

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

Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

2015-07-23 Thread Paul Carver

On a general topic of wiki cleanup, what's the preferred mechanism for 
documenting APIs?


Wiki page [1] largely duplicates the content of the spec in [2]
I dislike duplication of information because it's likely to get out of 
sync. I'd rather use hyperlinks whenever possible. However, linking to a 
Gerrit review isn't the most end user friendly way of presenting an API. 
One option is to link to the GitHub version of the rendered RST file [3] 
but I'd like to know if there are any other preferred practices.


[1] https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining
[2] https://review.openstack.org/#/c/192933/
[3] 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.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

[openstack-dev] [Neutron][SFC] Launchpad cleanup

2015-07-23 Thread Paul Carver

Is it possible to delete dead blueprints or at least change the section 
at the top to just provide a URL to the blueprint that supersedes it?


Blueprint [1] links to a bunch of abandoned reviews and references its 
parent Blueprint [2] which also links to abandoned work. The current 
work on service chaining is taking place under [3] and [4].



[1] https://blueprints.launchpad.net/neutron/+spec/neutron-service-chaining
[2] 
https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
[3] 
https://blueprints.launchpad.net/neutron/+spec/openstack-service-chain-framework
[4] 
https://blueprints.launchpad.net/neutron/+spec/neutron-api-extension-for-service-chaining


__
OpenStack Development Mailing List (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] [app-catalog] Catalog roadmap and next steps

2015-07-23 Thread Christopher Aedo

We have been making some progress on improvements to the Community App
Catalog, but this last month things have slowed down some.  I wanted
to send a note to the mailing list to get a conversation going about
what we need to get on the roadmap, and hopefully get some folks
committed to helping out.  We had been discussing some of this on IRC,
in addition to during the weekly scheduled meeting, but I am sure
we'll get a broader group engaged by covering this via email.

There are only a few blueprints noted at this time[1], but I plan to
add several shortly.  The blueprints I will add will cover the
design/functionality gaps that we are facing right now.  These
include:

-asset versions and exploring realistic ways to expose changes or
updates to assets without requiring visitors to review the repo
history
-integrating glance as the back-end for holding catalog assets (which
will help with search, sort and versions)
-horizon integration (Kevin Fox has begun work on this already)
-rating/scoring and comments/feedback for individual assets
-subscribing to an asset so users can be notified of updates/changes
-site
-UI changes to accommodate more types of assets

These alone represent a pretty good bit of work, but there's certainly
room to get more done over the next few months.  Considering the
impact the catalog could have on OpenStack adoption, I'd love to get
more feedback around the direction we're headed, and hopefully see
better participation.  (To that end if you'd like to catch us for a
real-time conversation on IRC, please do #openstack-app-catalog).

If you have any additional thoughts on things we could do to make the
catalog even more meaningful, or have feedback on the tasks ahead
please speak up :)  This is meant to be a place to find all the things
users of OpenStack clouds can do with their environments, so please
help us make this into the world class showcase it can be!

-Christopher
[1]: https://blueprints.launchpad.net/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

Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.

2015-07-23 Thread Tang Chen



On 07/24/2015 12:00 PM, Tang Chen wrote:


On 07/24/2015 10:08 AM, Tang Chen wrote:


On 07/23/2015 11:44 PM, Asselin, Ramy wrote:
Are you running on 'master' nodes? I remember seeing an issue where 
with a recent version of Jenkins or a plugin where it doesn't 
execute jobs on the master node.

But when run on non-master jenkins slaves, it works fine.


I checked my configuration, and made sure these things:
1. I have only a master node, no slave node.
2. I have 20 idle executors on master node.
3. My master node is online.
4. My master node is set to Utilize this node as much as possible.
5. zuul is able to be notified by Gerrit, and tell Jenkins to start 
jobs.


But the jobs are always pending.


And my Gearman reports this error sometimes.

2015-07-25 10:50:44,914 ERROR gear.Server: Exception in poll loop:
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/gear/__init__.py, line 
2614, in _doPollLoop

self._pollLoop()
  File /usr/local/lib/python2.7/dist-packages/gear/__init__.py, line 
2626, in _pollLoop

ret = self.poll.poll()
IOError: [Errno 4] Interrupted system call

Not sure if it has anything to do with this problem.

In Jenkins GUI, Gearman connection is tested successfully on 
127.0.0.1:4730.


Seeing from zuul debug log, Gearman has successfully submitted the jobs.

2015-07-25 11:42:09,255 DEBUG zuul.Scheduler: Adding trigger event: 
TriggerEvent patchset-created openstack-dev/sandbox master 205360,1
2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Done adding trigger event: 
TriggerEvent patchset-created openstack-dev/sandbox master 205360,1

2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Run handler awake
2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Fetching trigger event
2015-07-25 11:42:09,256 DEBUG zuul.Scheduler: Processing trigger event 
TriggerEvent patchset-created openstack-dev/sandbox master 205360,1
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager: Event 
TriggerEvent patchset-created openstack-dev/sandbox master 205360,1 
for change Change 0x7ff518312c10 205360,1 matched EventFilter types: 
patchset-created in pipeline IndependentPipelineManager check
2015-07-25 11:42:09,257 INFO zuul.Scheduler: Adding 
openstack-dev/sandbox, Change 0x7ff518312c10 205360,1 to Pipeline check
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager: 
Considering adding change Change 0x7ff518312c10 205360,1
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager: Checking 
for changes needed by Change 0x7ff518312c10 205360,1:
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager:   No 
changes needed
2015-07-25 11:42:09,257 DEBUG zuul.IndependentPipelineManager: Adding 
change Change 0x7ff518312c10 205360,1 to queue ChangeQueue check: 
openstack-dev/sandbox
2015-07-25 11:42:09,258 DEBUG zuul.IndependentPipelineManager: Event 
TriggerEvent patchset-created openstack-dev/sandbox master 205360,1 
for change Change 0x7ff518312c10 205360,1 matched EventFilter types: 
patchset-created in pipeline IndependentPipelineManager silent
2015-07-25 11:42:09,258 INFO zuul.Scheduler: Adding 
openstack-dev/sandbox, Change 0x7ff518312c10 205360,1 to Pipeline silent
2015-07-25 11:42:09,258 DEBUG zuul.IndependentPipelineManager: 
Considering adding change Change 0x7ff518312c10 205360,1
2015-07-25 11:42:09,258 DEBUG zuul.IndependentPipelineManager: Unable to 
find change queue for change Change 0x7ff518312c10 205360,1 in project 
openstack-dev/sandbox
2015-07-25 11:42:09,306 DEBUG zuul.IndependentPipelineManager: Starting 
queue processor: check
2015-07-25 11:42:09,306 DEBUG zuul.IndependentPipelineManager: Checking 
for changes needed by Change 0x7ff518312c10 205360,1:
2015-07-25 11:42:09,306 DEBUG zuul.IndependentPipelineManager:   No 
changes needed
2015-07-25 11:42:09,306 DEBUG zuul.IndependentPipelineManager: Preparing 
ref for: Change 0x7ff518312c10 205360,1
2015-07-25 11:42:09,307 INFO zuul.IndependentPipelineManager: Change 
Change 0x7ff518312c10 205360,1 depends on changes []
2015-07-25 11:42:09,307 DEBUG zuul.MergeClient: Submitting job gear.Job 
0x7ff518325490 handle: None name: merger:merge unique: 
b425daae0cec4ff3b0d4920ee5533c9c with data {'items': [{'oldrev': None, 
'newrev': None, 'refspec': u'refs/changes/60/205360/1', 'merge_mode': 2, 
'number': u'205360', 'project': 'openstack-dev/sandbox', 'url': 
'ssh://f...@review.openstack.org:29418/openstack-dev/sandbox', 'branch': 
u'master', 'patchset': u'1', 'ref': 'Z81183af13086459d9d9fb8c06af86c09'}]}
2015-07-25 11:42:09,308 DEBUG zuul.IndependentPipelineManager: Finished 
queue processor: check (changed: False)
2015-07-25 11:42:09,309 DEBUG zuul.IndependentPipelineManager: Starting 
queue processor: silent
2015-07-25 11:42:09,309 DEBUG zuul.IndependentPipelineManager: Finished 
queue processor: silent (changed: False)
2015-07-25 11:42:09,309 DEBUG zuul.IndependentPipelineManager: Starting 
queue processor: patch
2015-07-25 11:42:09,309 DEBUG zuul.IndependentPipelineManager: Finished

Re: [openstack-dev] [Monasca] Monasca mid-cycle meetup

2015-07-23 Thread Hochmuth, Roland M

Hi Chandeep, The official dates of the meet up are

When:
August 05-06 2015.

Where:
HP Building 6
Lower level (street level) Room C6/7 (6LC7/9)
3404 E Harmony Rd (Ziegler), Fort Collins, CO 80528, United States

The information is at the Etherpad. We'll probably start at around 8:30 or
9:00 AM MST both days.

Sorry about the short-notice.

Regards --Roland



On 7/23/15, 5:39 PM, Chandeep Khamba ckha...@cray.com wrote:

Roland, 

Could you please specify the time of the meetup , I need to book my
Airtickes accordingly

On 7/23/15, 4:30 PM, Chandeep Khamba ckha...@cray.com wrote:

Hi Roland,

I am still a newbie to Monasca  , but would like to hear and participate
in the agenda items we already have.
If I have something specific would definitely add it.

Thanks

On 7/23/15, 1:58 PM, Hochmuth, Roland M roland.hochm...@hp.com wrote:

Hi Chandeep, There are no fees. It would be great if you could join us.
Also, please feel free to add to the agenda topics that you would like
to
cover.

If you are traveling, I can advise on hotels.

Regards --Roland


From: Chandeep Khamba ckha...@cray.commailto:ckha...@cray.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.
o
r
g
Date: Thursday, July 23, 2015 at 2:16 PM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.
o
r
g
Subject: [openstack-dev] [Monasca] Monasca mid-cycle meetup

Hi,


Is the schedule for this meetup confirmed .
https://etherpad.openstack.org/p/monasca_liberty_mid_cycle

I would like to know if there is any fees involved to join in , or I
could just come in .

Thanks
CHandeep


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


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


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


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

[openstack-dev] [nova][v2.1 api calls]

2015-07-23 Thread Sajeesh Cimson Sasi

Hi All,
  Can you please tell me whether nova supports v2.1 api calls now. If 
so can you please tell me where the code is located.I can see the codes for 
v2(quotas.py) and v3(plugin/v3/quots_sets.py). I was thinking that  v2.1 is 
equivalent to v3 calls, since the api calls are looking similar.
  best regards,
   sajeesh

__
OpenStack Development Mailing List (not for 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][v2.1 api calls]

2015-07-23 Thread Ed Leafe

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/23/2015 09:16 PM, Sajeesh Cimson Sasi wrote:

 Can you please tell me whether nova supports v2.1 api calls now. If
 so can you please tell me where the code is located.I can see the
 codes for v2(quotas.py) and v3(plugin/v3/quots_sets.py). I was 
 thinking that  v2.1 is equivalent to v3 calls, since the api calls
 are looking similar.

Yes, the Kilo release contained support for the v2.1 API, as well as
the support for microversions for future changes. The code is still in
the v3 directory; this is a holdover from the original attempt to
create a new v3 API that would be backwards-incompatible, which was
later abandoned in favor of the microversion approach.

There is a current effort to clean up the code base by removing the
old 'v3' references since, as you have learned, the current layout is
confusing.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVsaI7AAoJEKMgtcocwZqLa5AP/0OAE/fJYupvNmvUvx0adna6
F6g7k24PTkerXufbLOXe1PDkihDXbJifpGJZQB2sgx9zz1AHppC6Hj+TV+8TyjJP
cnIQtAYhffEKUcFOpYrY/fYWTNJ7L6a510R2Ly1K8OWGlDcYrCNz+VCIjOiyxeXT
I+CrDRReeprQC3UsJT8NlJrX2rV3tWFk+G3NCHFUDxd9DTwn3N+XrPgkU7BvRB+R
eszGev95AcwCN13b3Wj8MxPvGvcaJVoY5X3/CMluiXfuVlLa37cxJJetwZPyJV+h
lTzhKnSsjWnp/UOd6TtOhXqrRA+cg+XraAAYxi79/EUvXpx0UQFtDZNGLMi21W53
viBG6zgIr8spxTGN3BCVvbv4wBkF8qaCH8w0cAqqwqqRofCfCXaf8M9ayLxVBbgN
21DgbvNr+9WrHfKcA+vd97lhWjJMqhZH/C90QdNRPNkkcoKULdNK559hEX8YkbkY
algWuamd16SbinoeTkW9BRi3NKuaJoP48aBh8xAIy26HVGFMDVG/eBDlIMvL3Gp+
rNjDT9YOahVb4OdTB51Mw89nki7RSTpUuqFZ+TY3SuBfXdfR8X36aYhrJpIDy5nY
G7LjIx+hFKx+EwUnC01qjl30IcDPLnnGsVyZus3L6xEtSSLcQByQ/5MSSCv7wQ9a
UVG0zz0akMVDEoz+LPiZ
=1Fu4
-END PGP SIGNATURE-

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

Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.

2015-07-23 Thread Tang Chen



On 07/24/2015 10:08 AM, Tang Chen wrote:


On 07/23/2015 11:44 PM, Asselin, Ramy wrote:
Are you running on 'master' nodes? I remember seeing an issue where 
with a recent version of Jenkins or a plugin where it doesn't execute 
jobs on the master node.

But when run on non-master jenkins slaves, it works fine.


I checked my configuration, and made sure these things:
1. I have only a master node, no slave node.
2. I have 20 idle executors on master node.
3. My master node is online.
4. My master node is set to Utilize this node as much as possible.
5. zuul is able to be notified by Gerrit, and tell Jenkins to start jobs.

But the jobs are always pending.


And my Gearman reports this error sometimes.

2015-07-25 10:50:44,914 ERROR gear.Server: Exception in poll loop:
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/gear/__init__.py, line 
2614, in _doPollLoop

self._pollLoop()
  File /usr/local/lib/python2.7/dist-packages/gear/__init__.py, line 
2626, in _pollLoop

ret = self.poll.poll()
IOError: [Errno 4] Interrupted system call

Not sure if it has anything to do with this problem.

In Jenkins GUI, Gearman connection is tested successfully on 127.0.0.1:4730.

Thanks.



I'm now trying to setup a slave node and try again. :)

And anyone has any idea of this, please let me know.

Thanks.


-Original Message-
From: Tang Chen [mailto:tangc...@cn.fujitsu.com]
Sent: Thursday, July 23, 2015 12:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [CI] Jenkins jobs are not executed when 
setting up a new CI system.


Hi, all

The Jenkins jobs submitted by zuul are always pending-Waiting for 
next available executor .


And Jenkins log shows the following:

Jul 24, 2015 11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl
submitFunction
WARNING:  Worker _exec-0 exception while executing function 
hudson.plugins.gearman.StartJobWorker

java.lang.RuntimeException: java.lang.RuntimeException:
java.util.concurrent.CancellationException
at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:136) 


at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:22) 


at
hudson.plugins.gearman.MyGearmanWorkerImpl.submitFunction(MyGearmanWorkerImpl.java:590) 


at
hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:374) 


at
hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166) 


at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException:
java.util.concurrent.CancellationException
at
hudson.plugins.gearman.StartJobWorker.executeFunction(StartJobWorker.java:116) 


at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:125) 


... 5 more
Caused by: java.util.concurrent.CancellationException
at hudson.remoting.AsyncFutureImpl.get(AsyncFutureImpl.java:77)
at
hudson.plugins.gearman.StartJobWorker.safeExecuteFunction(StartJobWorker.java:196) 


at
hudson.plugins.gearman.StartJobWorker.executeFunction(StartJobWorker.java:114) 


... 6 more

Jul 24, 2015 11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl work
INFO:  Worker _exec-0 sending initial grab job Jul 24, 2015 
11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl

handleSessionEvent
INFO:  Worker _exec-1 received unique job assignment Jul 24, 2015 
11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl work
INFO:  Worker _exec-1 executing function Jul 24, 2015 11:09:04 AM 
hudson.plugins.gearman.StartJobWorker

safeExecuteFunction
INFO:  Worker _exec-1 scheduling devstack-vm-test build #14 on 
with UUID 83d4fd10c1ad4f1ead51beb2adf23ccd and build params

[(StringParameterValue) BASE_LOG_PATH='03/204803/1',
(StringParameterValue) ZUUL_PIPELINE='check', (StringParameterValue) 
ZUUL_UUID='83d4fd10c1ad4f1ead51beb2adf23ccd', (StringParameterValue) 
LOG_PATH='03/204803/1/check/devstack-vm-test/83d4fd1',

(StringParameterValue) ZUUL_CHANGE_IDS='204803,1',
(StringParameterValue) ZUUL_PATCHSET='1', (StringParameterValue) 
ZUUL_BRANCH='master', (StringParameterValue) 
ZUUL_REF='refs/zuul/master/Z07d022076a68448d842bd1a47dd42e19',

(StringParameterValue)
ZUUL_COMMIT='174cac545549f086e07f32edbe34b70c4155a7fc',
(StringParameterValue) ZUUL_URL='http://10.124.196.205/p/',
(StringParameterValue) ZUUL_CHANGE='204803', (StringParameterValue) 
ZUUL_CHANGES='openstack-dev/sandbox:master:refs/changes/03/204803/1',

(StringParameterValue) ZUUL_PROJECT='openstack-dev/sandbox']


It seems that Gearman doesn't work properly.

Do you guys have any idea of this ?

Thanks.

__ 


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

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

__ 


OpenStack

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

2015-07-23 Thread Antoni Segura Puimedon

On Thu, Jul 23, 2015 at 8:10 PM, Stephen Wong stephen.kf.w...@gmail.com
wrote:

 +1 for Monday


+1 for Monday UTC. Maybe at 14 or 15h ?


 On Wed, Jul 22, 2015 at 10:29 PM, Mohammad Banikazemi m...@us.ibm.com
 wrote:

 Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I
 realize there are several networking related weekly meetings, but I would
 like to see if we can find a different time. I suggest the same time, that
 is 1600 UTC but either on Mondays or Thursdays.

 Please note there is the Ironic/Neutron Integration meeting at the same
 time on Mondays but that conflict may be a smaller conflict. Looking at the
 meetings listed at [2] I do not see any other conflict.

 Best,

 Mohammad

 [1] https://wiki.openstack.org/wiki/Meetings/ML2
 [2] http://eavesdrop.openstack.org


 [image: Inactive hide details for Gal Sagie ---07/22/2015 12:31:46
 PM---Hello Everyone, Project Kuryr is now officially part of Neutron]Gal
 Sagie ---07/22/2015 12:31:46 PM---Hello Everyone, Project Kuryr is now
 officially part of Neutron's big tent.

 From: Gal Sagie gal.sa...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org, Eran Gampel 
 eran.gam...@toganetworks.com, Antoni Segura Puimedon t...@midokura.com,
 Irena Berezovsky ir...@midokura.com
 Date: 07/22/2015 12:31 PM
 Subject: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking
 to Neutron
 --




 Hello Everyone,

 Project Kuryr is now officially part of Neutron's big tent.
 Kuryr is aimed to be used as a generic docker remote driver that connects
 docker to Neutron API's
 and provide containerised images for the common Neutron plugins.
 We also plan on providing common additional networking services API's
 from other sub projects
 in the Neutron big tent.

 We hope to get everyone on board with this project and leverage this
 joint effort for the many different solutions out there (instead of
 everyone re-inventing the wheel for each different project).

 We want to start doing a weekly IRC meeting to coordinate the different
 requierments and
 tasks, so anyone that is interested to participate please share your time
 preference
 and we will try to find the best time for the majority.

 Remember we have people in Europe, Tokyo and US, so we won't be able to
 find time that fits
 everyone.

 The currently proposed time is  *Wedensday at 16:00 UTC *

 Please reply with your suggested time/day,
 Hope to see you all, we have an interesting and important project ahead
 of us

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



 __
 OpenStack Development Mailing List (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][Kuryr][kolla] - Bringing Dockers networking to Neutron

2015-07-23 Thread Daneyon Hansen (danehans)

From: Antoni Segura Puimedon 
toni+openstac...@midokura.commailto:toni+openstac...@midokura.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, July 23, 2015 at 11:16 AM
To: Mohammad Banikazemi m...@us.ibm.commailto:m...@us.ibm.com, Steven Dake 
(stdake) std...@cisco.commailto:std...@cisco.com
Cc: Eran Gampel 
eran.gam...@toganetworks.commailto:eran.gam...@toganetworks.com, OpenStack 
Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Irena Berezovsky ir...@midokura.commailto:ir...@midokura.com
Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers 
networking to Neutron

On Thu, Jul 23, 2015 at 7:35 PM, Mohammad Banikazemi 
m...@us.ibm.commailto:m...@us.ibm.com wrote:

I let the creators of the project speak for themselves but here is my take on 
project Kuryr.

The goal is not to containerize Neutron or other OpenStack services. The main 
objective is to use Neutron as a networking backend option for Docker. The 
original proposal was to do so in the context of using containers (for 
different Neutron backends or vif types). While the main objective is 
fundamental to the project, the latter (use of containers in this particular 
way) seems to be a tactical choice we need to make. I see several different 
options available to achieve the same goal in this regard.

Thanks Mohammad. It is as you say, the goal of Kuryr to provide Docker with a 
new libnetwork remote
driver that is powered by Neutron, not a containerization of Neutron. Kuryr 
deployments as you point out,
may opt to point to a Neutron that is containerized, and for that I was looking 
at using Kolla. However,
that is just deployment and I consider it to be something up to the deployer 
(of course, we'll make Kuryr
containerizable and part of Kolla :-) ).

The design for interaction/configuration is not yet final, as I still have to 
push drafts for the blueprints and
get comments, but my initial idea is that you will configure docker to pass the 
configuration of which
device to take hold of for the overlay and where the neutron api are in the 
following way.

$ docker -d --kv-store=consul:localhost:8500 
--label=com.docker.network.driver.kuryr.bind_interface=eth0 
--label=com.docker.network.driver.kuryr.neutron_api=10.10.10.10
--label=com.docker.network.driver.kuryr.token=AUTH_tk713d067336d21348bcea1ab220965485

Why is a separate OpenStack project needed to contribute to libnetwork? I would 
think the Neutron community would follow the libnetwork contrib guidelines and 
submit the code.

Another possibility is that those values were passed as env variables or plain 
old configuration files.

Now, there is another aspect of using containers in the context of this project 
that is more interesting at least to me (and I do not know if others share this 
view or not) and that is the use of containers for providing network services 
that are not available through libnetwork as of now or in near future or ever. 
From the talks I have had with libnetwork developers the plan is to stay with 
the basic networking infrastructure and leave additional features to be 
developed by the community and to do so possibly by using what else, containers.

So take the current features available in libnetwork. You mainly get support 
for connectivity/isolation for multiple networks across multiple hosts. Now if 
you want to route between these networks, you have to devise a solution 
yourself. One possible solution would be having a router service in a container 
that gets connected to say two Docker networks. Whether the router service is 
implemented with the use of the current Neutron router services or by some 
other solutions is something to look into and discuss but this is a direction 
where I think Kuryr (did I spell it right? ;)) can and should contribute to.

You got that right. The idea is indeed to get the containers networked via 
libnetwork that, as you point out,
was left intentionally simple to be developed by the community; then we want to 
make make:

a) Kuryr get the containers to networks that have been pre-configured with 
advanced networking (lb, sec groups, etc).
Being able to perform changes on those networks via neutron after the fact as 
well. For example the container
orchestration software could create a Neutron network with a load balancer and 
a FIP, start containers on that network
and add them to the load balancer.
b) Via the usage of either docker labels on `docker run` make Kuryr implicitly 
set up Neutron networks/topologies.

Yup, you spelled it well. In Czech it is Kurýr, but for project purposes I 
dropped the ´
Thanks a lot for contributing and I'm very happy to see that you got a very 
good sense for the direction we are taking.
I'm looking forward to meet you all in the community meetings!

Just my 2 cents

Re: [openstack-dev] [requirements][all] stop merging requirements changes

2015-07-23 Thread Robert Collins

On 24 July 2015 at 05:02, Doug Hellmann d...@doughellmann.com wrote:
 Because of a faulty test, we've been merging some bad requirements
 changes. Please do not approve any more changes until the fixes for the
 tests have been merged:

 https://review.openstack.org/#/c/204181
 https://review.openstack.org/#/c/204198

Sorry to be slow reviewing those, travel to the and paying attention
to the midcycle distracted me.

I've given them a review now, but there are some issues. Since they
are urgent, would you like me to pick them up and apply my desired
changes to them for you?

-Rob



-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [Ironic] [Oslo] Question about Futurist executors

2015-07-23 Thread Joshua Harlow

An example/poc that adds a basic rejection mechanism to various 
executors (the process pool excecutor internals are complicated and 
doesn't implement it for that).


https://review.openstack.org/205262

With that the following (or similar) could be done:

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

Comments welcome, ideally https://bugs.python.org/issue22737  would be 
much more improved than that, but the general idea is the same...


Joshua Harlow wrote:

Dmitry Tantsur wrote:

Jim,

I'm redirecting your question to oslo folks, as I'm afraid my answer can
be wrong.

On 07/23/2015 01:55 PM, Jim Rollenhagen wrote:

On Wed, Jul 22, 2015 at 02:40:47PM +0200, Dmitry Tantsur wrote:

Hi all!

Currently _spawn_worker in the conductor manager raises
NoFreeConductorWorker if pool is already full. That's not very user
friendly
(potential source of retries in client) and does not map well on common
async worker patterns.

My understanding is that it was done to prevent the conductor thread
from
waiting on pool to become free. If this is true, we no longer need it
after
switch to Futurist, as Futurist maintains internal queue for its green
executor, just like thread and process executors in stdlib do.
Instead of
blocking the conductor the request will be queued, and a user won't
have to
retry vague (and rare!) HTTP 503 error.

WDYT about me dropping this exception with move to Futurist?



I kind of like this, but with my operator hat on this is a bit scary.
Does Futurist just queue all requests indefinitely? Is it configurable?
Am I able to get any insight into the current state of that queue?


I believe answer is no, and the reason IIUC is that Futurist executors
are modeled after stdlib executors, but I may be wrong.


So this is correct, currently executors will queue things up, and that
queue may get very large. In futurist we can work on making this better,
although to do it correctly we really need
https://bugs.python.org/issue22737 and that needs upstream python
adjustments to make it possible.

Without that https://bugs.python.org/issue22737 being implemented its
not to hard to limit the work queue yourself, but it will have to be
something extra and require tracking of your own.

For example:

dispatched = set()

def on_done(fut):
dispatched.discard(fut)

executor = futurist.GreenThreadPoolExecutor()

...

if len(dispatched)  MAX_DISPATCH:
raise IamToOverWorkedExeception(...)

fut = executor.submit(some_work)
dispatched.add(fut)
fut.add_done_callback(on_done)

The above will limit how much work is done at the same time
(https://bugs.python.org/issue22737 makes it work more like java, which
has executor rejection policies,
http://download.java.net/jdk7/archive/b123/docs/api/java/util/concurrent/RejectedExecutionHandler.html)
but you can limit this yourself pretty easily... Making issue22737
happen would be great; I just haven't had enough time to pull that off...





Just indefinitely queueing up everything seems like it could end with a
system that's backlogged to death, with no way to determine if that's
actually the problem or not.


As for metrics, one of the additions of the futurist executor subclasses
was to bolt-on the following being gathered,
https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L387
(at executor property '.statistics') so hopefully that can help u learn
about what your executors are doing as well..



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


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

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature

2015-07-23 Thread Mike Scherbakov

Hi Andrian,
this is High priority blueprint [1] for 7.0 timeframe. It seems we still
didn't merge the main part [2], and need FF exception for additional stuff.

The question is about quality. If we focus on enhancements, then we don't
focus on bugs. Which whether means to deliver work with lower quality of
slip the release.

My opinion is rather don't give FF exception in this case, and don't have
Ceilometer support for this new feature.

[1] https://blueprints.launchpad.net/fuel/+spec/compute-vmware-role
[2] https://review.openstack.org/#/c/196114/

On Thu, Jul 23, 2015 at 1:39 PM Andrian Noga an...@mirantis.com wrote:

 Hi,

 The patch patch for fuel-library
 https://review.openstack.org/#/c/196114/  that implements
 'compute-vwmare' role (https://mirantis.jira.com/browse/PROD-627) requires
 additional work to do (ceilometer support.), but as far as I can see it
 doesn't affect any other parts of the product.

 We plan to implement it in 3 working days (2 for implementation, 1 day
 for writing system test and test runs), it should not be hard since we
 already support ceilometer compute agent deployment on controller nodes.

 We need 1 DevOps engineer and 1 QA engineer to be engaged for this work.

 So I think it's ok to accept this feature as an exception for feature
 freeze.

 Regards,
 Andrian Noga
 Project manager
 Partner Centric Engineering
 Mirantis, Inc

 Mob.phone: +38 (063) 966-21-24

 Email: an...@mirantis.com
 Skype: bigfoot_ua

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

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

2015-07-23 Thread Markus Zoeller

Sean Dague s...@dague.net wrote on 07/23/2015 01:50:00 PM:

 From: Sean Dague s...@dague.net
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 07/23/2015 01:50 PM
 Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config 
 options in nova

 [...] 
 Maybe a directory is fine, especially if module mapped to [subsection].

 nova/config/
default.py
glance.py
...

 which makes it reasonably discoverable and mappable back and forth from
 config file to files.

-Sean

+1 

Regards,
Markus Zoeller (markus_z)

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

[openstack-dev] [Fuel] 7.0 Release - Feature Freeze in action

2015-07-23 Thread Eugene Bogdanov


Hello everyone,

Please be informed that we have officially entered Feature Freeze state 
for Fuel 7.0 Release. This means that since now on we focus on bugfixing 
and stop accepting new code except bugfix commits. If you believe that 
the code for your feature still needs to be merged as an exception, 
please file an exception request as described in [1].


3 Feature Freeze Exception requests have already been filed [2]. We're 
working closely with Feature Leads and Core Reviewers to assess risks 
and additional time estimations. We expect to take decisions on all 3 
cases by tomorrow EOD Pacific Time and communicate them in respective 
threads.


Thanks everyone for your contributions and collaborative efforts. Let's 
keep up good work.


--
EugeneB

[1] https://wiki.openstack.org/wiki/FeatureFreeze

[2] Exception requests:

#1: Environment Upgrade extensions for Nailgun API:
https://review.openstack.org/#/c/192551/

#2: CLI changes of working with custom node labels:
_https://review.openstack.org/#/c/204524/_

#3: Fernet Tokens support:
https://review.openstack.org/#/c/201029/
__
OpenStack Development Mailing List (not for 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][Kuryr][kolla] - Bringing Dockers networking to Neutron

2015-07-23 Thread Mohammad Banikazemi

Daneyon Hansen (danehans) daneh...@cisco.com wrote on 07/23/2015
03:40:38 PM:

 From: Daneyon Hansen (danehans) daneh...@cisco.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org, Mohammad Banikazemi/Watson/
 IBM@IBMUS, Steven Dake (stdake) std...@cisco.com
 Cc: Eran Gampel eran.gam...@toganetworks.com, Irena Berezovsky
 ir...@midokura.com
 Date: 07/23/2015 03:45 PM
 Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing
 Dockers networking to Neutron

 From: Antoni Segura Puimedon toni+openstac...@midokura.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)

 openstack-dev@lists.openstack.org
 Date: Thursday, July 23, 2015 at 11:16 AM
 To: Mohammad Banikazemi m...@us.ibm.com, Steven Dake (stdake) 
 std...@cisco.com
 Cc: Eran Gampel eran.gam...@toganetworks.com, OpenStack
 Development Mailing List (not for usage questions) openstack-
 d...@lists.openstack.org, Irena Berezovsky ir...@midokura.com
 Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing
 Dockers networking to Neutron

 Why is a separate OpenStack project needed to contribute to
 libnetwork? I would think the Neutron community would follow the
 libnetwork contrib guidelines and submit the code.

While there may be contributions to docker/libnetwork at some point, the
project is not about contributing to libnetwork. For example, the Neutron
driver itself won't be part of the docker or libnetwork tree. Making other
OpenStack and Neutron services available for use by containers may be a
good reason  for having it under the OpenStack and Neutron umbrella but I
think one can debate where a project fits best.

Best,

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

Re: [openstack-dev] [fuel][CI] Fuel-web CI is broken

2015-07-23 Thread Mike Scherbakov

Have we resolved this? What is the long term strategy on this?

On Mon, Jul 20, 2015 at 10:51 PM Andrew Woodward awoodw...@mirantis.com
wrote:

 I found this after noon that fuel-web CI was broken due to the recent
 release of oslo.config and oslo.utils 2.0.0 [1]

 I attempted to muck around with the pinning of the requirements.txt and
 had initial success with it [2] but later found that it's failing the
 test_check_requirements_conflicts task. I'm at a loss on how to properly
 fix the requirements for pbr here.

 I've also started another commit to get fuel web off of the old namespace
 [4]

 [1] https://bugs.launchpad.net/fuel/+bug/1476399
 [2] https://review.openstack.org/#/c/203824
 [3]
 https://ci.fuel-infra.org/job/verify-fuel-web/2626/testReport/nailgun.test.unit/test_requirements/test_check_requirements_conflicts/
 [4] https://review.openstack.org/#/c/203847/
 --
 --
 Andrew Woodward
 Mirantis
 Fuel Community Ambassador
 Ceph Community

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

[openstack-dev] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature

2015-07-23 Thread Andrian Noga

Hi,

The patch patch for fuel-library https://review.openstack.org/#/c/196114/
 that implements 'compute-vwmare' role (
https://mirantis.jira.com/browse/PROD-627) requires additional work to
do (ceilometer
support.), but as far as I can see it doesn't affect any other parts of the
product.

We plan to implement it in 3 working days (2 for implementation, 1 day for
writing system test and test runs), it should not be hard since we already
support ceilometer compute agent deployment on controller nodes.

We need 1 DevOps engineer and 1 QA engineer to be engaged for this work.

So I think it's ok to accept this feature as an exception for feature
freeze.

Regards,
Andrian Noga
Project manager
Partner Centric Engineering
Mirantis, Inc

Mob.phone: +38 (063) 966-21-24
Email: an...@mirantis.com
Skype: bigfoot_ua
__
OpenStack Development Mailing List (not for 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][Kuryr][kolla] - Bringing Dockers networking to Neutron

2015-07-23 Thread Mohammad Banikazemi




 $ docker -d --kv-store=consul:localhost:8500 --
 label=com.docker.network.driver.kuryr.bind_interface=eth0 --
 label=com.docker.network.driver.kuryr.neutron_api=10.10.10.10

--label=com.docker.network.driver.kuryr.token=AUTH_tk713d067336d21348bcea1ab220965485


Toni, Why do you want to have this configuration parameters known to
docker? Docker uses a plugin through the libnetwork remote driver. What
that plugin does and how for example it gets to the Neutron server is what
the plugin has to deal with. No?

I can see some information regarding IP address management may be relevant
to docker and I see the use of labels but think other parameters should not
be of concern to docker.

You have referred to use of an authentication token. I think that is a
possible place were labels can be eventually used for identifying different
tenants/users but that requires a longer discussion.

Best,

Mohammad
__
OpenStack Development Mailing List (not for 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] token revocation woes

2015-07-23 Thread Lance Bragstad

On Wed, Jul 22, 2015 at 10:06 PM, Adam Young ayo...@redhat.com wrote:

  On 07/22/2015 05:39 PM, Adam Young wrote:

 On 07/22/2015 03:41 PM, Morgan Fainberg wrote:

 This is an indicator that the bottleneck is not the db strictly speaking,
 but also related to the way we match. This means we need to spend some
 serious cycles on improving both the stored record(s) for revocation events
 and the matching algorithm.


 The simplest approach to revocation checking is to do a linear search
 through the events.  I think the old version of the code that did that is
 in a code review, and I will pull it out.

 If we remove the tree, then the matching will have to run through each of
 the records and see if there is a match;  the test will be linear with the
 number of records (slightly shorter if a token is actually revoked).


 This was the origianal, linear search version of the code.


 https://review.openstack.org/#/c/55908/50/keystone/contrib/revoke/model.py,cm



What initially landed for Revocation Events was the tree-structure, right?
We didn't land a linear approach prior to that and then switch to the tree,
did we?







 Sent via mobile

 On Jul 22, 2015, at 11:51, Matt Fischer m...@mattfischer.com wrote:

   Dolph,

  Per our IRC discussion, I was unable to see any performance improvement
 here although not calling DELETE so often will reduce the number of
 deadlocks when we're under heavy load especially given the globally
 replicated DB we use.



 On Tue, Jul 21, 2015 at 5:26 PM, Dolph Mathews dolph.math...@gmail.com
 wrote:

 Well, you might be in luck! Morgan Fainberg actually implemented an
 improvement that was apparently documented by Adam Young way back in
 March:

   https://bugs.launchpad.net/keystone/+bug/1287757

  There's a link to the stable/kilo backport in comment #2 - I'd be eager
 to hear how it performs for you!

 On Tue, Jul 21, 2015 at 5:58 PM, Matt Fischer m...@mattfischer.com
 wrote:

  Dolph,

  Excuse the delayed reply, was waiting for a brilliant solution from
 someone. Without one, personally I'd prefer the cronjob as it seems to be
 the type of thing cron was designed for. That will be a painful change as
 people now rely on this behavior so I don't know if its feasible. I will be
 setting up monitoring for the revocation count and alerting me if it
 crosses probably 500 or so. If the problem gets worse then I think a custom
 no-op or sql driver is the next step.

  Thanks.


 On Wed, Jul 15, 2015 at 4:00 PM, Dolph Mathews dolph.math...@gmail.com
 wrote:



 On Wed, Jul 15, 2015 at 4:51 PM, Matt Fischer m...@mattfischer.com
 wrote:

 I'm having some issues with keystone revocation events. The bottom
 line is that due to the way keystone handles the clean-up of these
 events[1], having more than a few leads to:

   - bad performance, up to 2x slower token validation with about 600
 events based on my perf measurements.
  - database deadlocks, which cause API calls to fail, more likely with
 more events it seems

  I am seeing this behavior in code from trunk on June 11 using Fernet
 tokens, but the token backend does not seem to make a difference.

  Here's what happens to the db in terms of deadlock:
 2015-07-15 21:25:41.082 31800 TRACE keystone.common.wsgi DBDeadlock:
 (OperationalError) (1213, 'Deadlock found when trying to get lock; try
 restarting transaction') 'DELETE FROM revocation_event WHERE
 revocation_event.revoked_at  %s' (datetime.datetime(2015, 7, 15, 18, 55,
 41, 55186),)

  When this starts happening, I just go truncate the table, but this
 is not ideal. If [1] is really true then the design is not great, it 
 sounds
 like keystone is doing a revocation event clean-up on every token
 validation call. Reading and deleting/locking from my db cluster is not
 something I want to do on every validate call.


  Unfortunately, that's *exactly* what keystone is doing. Adam and I
 had a conversation about this problem in Vancouver which directly resulted
 in opening the bug referenced on the operator list:

   https://bugs.launchpad.net/keystone/+bug/1456797

  Neither of us remembered the actual implemented behavior, which is
 what you've run into and Deepti verified in the bug's comments.



  So, can I turn of token revocation for now? I didn't see an obvious
 no-op driver.


  Not sure how, other than writing your own no-op driver, or perhaps an
 extended driver that doesn't try to clean the table on every read?


  And in the long-run can this be fixed? I'd rather do almost anything
 else, including writing a cronjob than what happens now.


  If anyone has a better solution than the current one, that's also
 better than requiring a cron job on something like keystone-manage
 revocation_flush I'd love to hear it.


  [1] -
 http://lists.openstack.org/pipermail/openstack-operators/2015-June/007210.html


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

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

2015-07-23 Thread Yapeng Wu

Gal, I vote for Monday 1600UTC.

Thanks,
Yapeng

From: Mohammad Banikazemi [mailto:m...@us.ibm.com]
Sent: Thursday, July 23, 2015 1:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Eran Gampel; Irena Berezovsky; Antoni Segura Puimedon
Subject: Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to 
Neutron

Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I 
realize there are several networking related weekly meetings, but I would like 
to see if we can find a different time. I suggest the same time, that is 1600 
UTC but either on Mondays or Thursdays.

Please note there is the Ironic/Neutron Integration meeting at the same time on 
Mondays but that conflict may be a smaller conflict. Looking at the meetings 
listed at [2] I do not see any other conflict.

Best,

Mohammad

[1] https://wiki.openstack.org/wiki/Meetings/ML2
[2] http://eavesdrop.openstack.orghttp://eavesdrop.openstack.org/

[Inactive hide details for Gal Sagie ---07/22/2015 12:31:46 PM---Hello 
Everyone, Project Kuryr is now officially part of Neutron]Gal Sagie 
---07/22/2015 12:31:46 PM---Hello Everyone, Project Kuryr is now officially 
part of Neutron's big tent.

From: Gal Sagie gal.sa...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org, Eran Gampel 
eran.gam...@toganetworks.com, Antoni Segura Puimedon t...@midokura.com, 
Irena Berezovsky ir...@midokura.com
Date: 07/22/2015 12:31 PM
Subject: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to 
Neutron

Hello Everyone,

Project Kuryr is now officially part of Neutron's big tent.
Kuryr is aimed to be used as a generic docker remote driver that connects 
docker to Neutron API's
and provide containerised images for the common Neutron plugins.
We also plan on providing common additional networking services API's from 
other sub projects
in the Neutron big tent.

We hope to get everyone on board with this project and leverage this joint 
effort for the many different solutions out there (instead of everyone 
re-inventing the wheel for each different project).

We want to start doing a weekly IRC meeting to coordinate the different 
requierments and
tasks, so anyone that is interested to participate please share your time 
preference
and we will try to find the best time for the majority.

Remember we have people in Europe, Tokyo and US, so we won't be able to find 
time that fits
everyone.

The currently proposed time is  Wedensday at 16:00 UTC

Please reply with your suggested time/day,
Hope to see you all, we have an interesting and important project ahead of us

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

__
OpenStack Development Mailing List (not for 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] Status of identity v3 support

2015-07-23 Thread Matt Riedemann




On 7/22/2015 10:18 PM, Adam Young wrote:

On 07/15/2015 06:38 PM, melanie witt wrote:

Hi Everyone,

Recently I have started reviewing the patch series about nested quotas in nova [1] and 
I'm having trouble understanding where we currently are with identity v3 support in nova. 
From what I read in a semi recent proposal [2] I think things mostly just 
work if you configure to run with v3, but there are some gaps.

Nested quotas use the concept of parent/child projects in keystone v3 to allow 
parent projects to delegate quota management to subprojects. This means we'd 
start getting requests with a token scoped to the parent project to modify 
quota of a child project.


Don't think of it as a nested project, in this case...The project that
is having its quota set is a resource inside the project that the user
authenticated in as.


If Parent - child...you should not be able to scope to anything but the
parent project in order to be able to set the quota for child.

But, you should not be able to do anything inside of child with a token
scoped to parent.

The one place this gets tricky is that every project should be able to
query its own quota.  But that is true now, is it not?


You can, the default policy for show is admin_or_owner:

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json?id=12.0.0.0b1#n333






With keystone v3 we could get requests with tokens scoped to parent projects 
that act upon child project resources for all APIs in general.

The first patch in the series [3] removes the top-level validation check for 
context.project_id != project_id in URL, since with v3 it's a supported thing 
for a parent project to act on child project resources. (I don't think it's 
completely correct in that I think it would allow unrelated projects to act on 
one another)

Doing this fails the keypairs and security groups tempest tests [4] that verify 
that one project cannot create keypairs or security group rules in a different 
project.

Question: How can we handle project_id mismatch in a way that supports both keystone v2 
and v3? Do we augment the check to fall back on checking if is parent of 
using keystone API if there's a project_id mismatch?

Question: Do we intend to, for example, allow creation of keypairs by a parent 
on behalf of child being that the private key is returned to the caller?

Basically, I feel stuck on these reviews because it appears to me that nova 
doesn't fully support identity v3 yet. From what I checked, there aren't yet 
Tempest jobs running against identity v3 either.

Can anyone shed some light on this as I'm trying to see a way forward with the 
nested quotas reviews?

Thanks,
-melanie (irc: melwitt)


[1]https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z
[2]https://review.openstack.org/#/c/103617/
[3]https://review.openstack.org/182140/
[4]http://logs.openstack.org/40/182140/12/check/check-tempest-dsvm-full/8e51c94/logs/testr_results.html.gz



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



--

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][L3] Representing a networks connected by routers

2015-07-23 Thread Carl Baldwin

On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton blak...@gmail.com wrote:
It seems to me that the existence of the multiprovider extension is an
 important point for this discussion.  Multiprovider, as I understand it,
 allows describing a network composed of multiple L2 segments with implicit
 east-west routing between them.

 Not quite. Multiprovider is to describe different L2 segments that are all
 connected together via some kind of translator (e.g. l2 gateway) that
 ensures they are all part of the same broadcast domain. It doesn't fit with
 what we are looking to achieve because all of the segments are supposed to
 be part of the same broadcast domain so there is only one DHCP instance for
 all segments, subnets are shared between all of them, a router only attaches
 to one, etc.

I share Kevin's understanding of multi-provider networks.  Well-stated, Kevin.

But I was suggesting that there might be some scenarios where routing
 happened without a corresponding router object, and in fact it appears
 that this is already the case: between the segments of a multiprovider
 network.

 There isn't routing between different subnets for multiprovider networks. A
 multiprovider network is just an l2 broadcast domain realized on multiple
 encapsulation mediums.

This was my understanding too.

I think Ian's posts have now clarified this.  The current order of
 events is:
- Neutron creates an unbound port, associated with a network, and
 allocates an IP address for it.
- Nova chooses a host for the new VM.
- The port is bound and plugged on that host.

 This is only the case if someone passes a port UUID into Nova to use. If
 Nova creates the port itself, it will wait until it's scheduled to a compute
 node so the port creation request should already have the host_id field set.

I like this better than delaying IP address assignment until host
binding occurs.

 Supporting the case a pre-created port and migration will be the issue. We
 would essentially need to allow ports to be re-assigned to different
 networks to handle these scenarios.

Or, migration scheduling would need to respect the constraint that a
port may be confined to a set of hosts.  How can be assign a port to a
different network?  The VM would wake up and what?  How would it know
to reconfigure its network stack?

Carl

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

[openstack-dev] [cross-project] Admin ness not properly scoped

2015-07-23 Thread Adam Young

I a user has an admin role anywhere, they have it everywhere.  This is 
bug https://bugs.launchpad.net/keystone/+bug/968696 and, in order to fix 
it we are going to have to adjust our thinking on policy checks.


Here is the theory:
A user is assigned a role on a project.  Policy uses the roles assigned 
in the token to see if the user has access to the object.


This breaks down in practice.  The policy checks either look for a role  
OR a project.


The role is almost always Admin

If that fails, then look to see if the user has a project assigned in 
the token.


What this means is the if a user is assigned admin on any project, 
they are assigned admin for everything.


Fixing this is going to require a change to how we write policy.

Each policy rule needs to have two parts:

1.  Match the scoped of the token (project for everything that is not 
Keystone, project or domain for Keystone).


2.  Match the role.

Only the second part should ever be changed on a deployment.  It is ok 
to take a rule that is normally executable by A Member and say that it 
is Admin only.  or, if you are so included, define new roles, like 
Manager, which can perform some operations different than Member or Admin.


The first part should not be modified.  It is an engineering decision to 
say here is where we find the scope in this API.  How to find the Scope 
varies from call to call, and changing that part of the rule is likely 
to break the policy check.



There should be no  Global Admin Tokens.  They are a security risk, 
and violate the principal of Least Privilege. 
https://en.wikipedia.org/wiki/Principle_of_least_privilege.





__
OpenStack Development Mailing List (not for 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][L3] Representing a networks connected by routers

2015-07-23 Thread Kevin Benton

Or, migration scheduling would need to respect the constraint that a
port may be confined to a set of hosts.  How can be assign a port to a
different network?  The VM would wake up and what?  How would it know
to reconfigure its network stack?

Right, that's a big mess. Once a network is picked for a port I think we
just need to rely on a scheduler filter that limits the migration to where
that network is available.
On Jul 23, 2015 8:28 AM, Carl Baldwin c...@ecbaldwin.net wrote:

 On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton blak...@gmail.com wrote:
 It seems to me that the existence of the multiprovider extension is an
  important point for this discussion.  Multiprovider, as I understand it,
  allows describing a network composed of multiple L2 segments with
 implicit
  east-west routing between them.
 
  Not quite. Multiprovider is to describe different L2 segments that are
 all
  connected together via some kind of translator (e.g. l2 gateway) that
  ensures they are all part of the same broadcast domain. It doesn't fit
 with
  what we are looking to achieve because all of the segments are supposed
 to
  be part of the same broadcast domain so there is only one DHCP instance
 for
  all segments, subnets are shared between all of them, a router only
 attaches
  to one, etc.

 I share Kevin's understanding of multi-provider networks.  Well-stated,
 Kevin.

 But I was suggesting that there might be some scenarios where routing
  happened without a corresponding router object, and in fact it appears
  that this is already the case: between the segments of a multiprovider
  network.
 
  There isn't routing between different subnets for multiprovider
 networks. A
  multiprovider network is just an l2 broadcast domain realized on multiple
  encapsulation mediums.

 This was my understanding too.

 I think Ian's posts have now clarified this.  The current order of
  events is:
 - Neutron creates an unbound port, associated with a network, and
  allocates an IP address for it.
 - Nova chooses a host for the new VM.
 - The port is bound and plugged on that host.
 
  This is only the case if someone passes a port UUID into Nova to use. If
  Nova creates the port itself, it will wait until it's scheduled to a
 compute
  node so the port creation request should already have the host_id field
 set.

 I like this better than delaying IP address assignment until host
 binding occurs.

  Supporting the case a pre-created port and migration will be the issue.
 We
  would essentially need to allow ports to be re-assigned to different
  networks to handle these scenarios.

 Or, migration scheduling would need to respect the constraint that a
 port may be confined to a set of hosts.  How can be assign a port to a
 different network?  The VM would wake up and what?  How would it know
 to reconfigure its network stack?

 Carl

 __
 OpenStack Development Mailing List (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] Create a network filter

2015-07-23 Thread Silvia Fichera

Hi all,

I'm using OpenStack together with OpenDaylight to add a network awareness
feature to the scheduler.
I have 3 compute nodes (one of these is also the Openstack Controller)
connected by a openvswitch controlled by OpenDaylight.
What I would like to do is to write a filter to check if a link is up and
then assign weight acconding to the available bw (I think I will collect
this data by ODL and update an entry in a db).
For each host I have a management interface (eth0) and an interface
connected to the OVS switch to build the physical network (eth1).
Have you got any suggestion to check the link status?
I thought I can be inspired by the second script in this link
http://stackoverflow.com/questions/17434079/python-check-to-see-if-host-is-connected-to-network
to verify if the iface is up and then check the connectivity but It has to
be run in the compute node and I don't know which IP address I could point
at.


Thank you

-- 
Silvia Fichera
__
OpenStack Development Mailing List (not for 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][L3] Representing a networks connected by routers

2015-07-23 Thread Carl Baldwin

On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton blak...@gmail.com wrote:
Or, migration scheduling would need to respect the constraint that a
 port may be confined to a set of hosts.  How can be assign a port to a
 different network?  The VM would wake up and what?  How would it know
 to reconfigure its network stack?

 Right, that's a big mess. Once a network is picked for a port I think we
 just need to rely on a scheduler filter that limits the migration to where
 that network is available.

+1.  That's where I was going.

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

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Aleksandr Didenko

Hi,

Am I alone in thinking it's not the best use of our development
resources to throw it away and replace it with a text file that is
edited by hand?

Nope. I'm with you :)

Many people prefer vim UX instead of wandering through the semi-graphical
interface.

Are those ppl developers or end-users/customers?

Regards,
Alex

On Thu, Jul 23, 2015 at 5:26 PM, Oleg Gelbukh ogelb...@mirantis.com wrote:

Unless I am mistaken, it is possible to set most of the parameters
supported by Fuel menu as kernel boot parameters. Isn't it sufficient
replacement for fuelmenu for dev's purposes?

-Oleg

On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mmoses...@mirantis.com
wrote:

How much effort are we spending? I'm not so sure it's a major development
drain.

Since Fuel 6.0 dev cycle (Sept 2014) until now there have been 34
commits into Fuelmenu:
* New features/functionality: 12
* Bugfix: 15
* Other: 7 (version bumps, and commits without bug ID)

https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp

Am I alone in thinking it's not the best use of our development
resources to throw it away and replace it with a text file that is
edited by hand?

On Thu, Jul 23, 2015 at 3:33 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
Hello,

Here's my 2 cents on it.

I'm agree with Vladimir, vim + config files are enough, since Fuel is
not a product for housewives. It's a product for those who do not
hesitate to use Vim for soft configuration.

Thanks,
Igor

This topic comes up once a year only from Fuel Python developers
because they rarely use it and no dev cycles have been invested in
improving it.

The actual Fuel deployers use it and appreciate its validation and
wish to extend it.

I'd like to hear more feedback.

On Thu, Jul 23, 2015 at 2:23 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Dear colleagues,

What do you think of getting rid of fuelmenu and substituting it with
thoroughly commented text file + some validation + vim? The major pro
of
this is that text file is easier to extend and edit. Many people
prefer vim
UX instead of wandering through the semi-graphical interface. And it
is not
so hard to implement syntax and logic checking for the text file.

Please give your opinions about this.

Vladimir Kozhukalov

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

__
OpenStack

Re: [openstack-dev] [nova] Status of identity v3 support

2015-07-23 Thread Adam Young


On 07/23/2015 10:08 AM, Matt Riedemann wrote:



On 7/22/2015 10:18 PM, Adam Young wrote:

On 07/15/2015 06:38 PM, melanie witt wrote:

Hi Everyone,

Recently I have started reviewing the patch series about nested 
quotas in nova [1] and I'm having trouble understanding where we 
currently are with identity v3 support in nova. From what I read in 
a semi recent proposal [2] I think things mostly just work if you 
configure to run with v3, but there are some gaps.


Nested quotas use the concept of parent/child projects in keystone 
v3 to allow parent projects to delegate quota management to 
subprojects. This means we'd start getting requests with a token 
scoped to the parent project to modify quota of a child project.


Don't think of it as a nested project, in this case...The project that
is having its quota set is a resource inside the project that the user
authenticated in as.


If Parent - child...you should not be able to scope to anything but the
parent project in order to be able to set the quota for child.

But, you should not be able to do anything inside of child with a token
scoped to parent.

The one place this gets tricky is that every project should be able to
query its own quota.  But that is true now, is it not?


You can, the default policy for show is admin_or_owner:

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json?id=12.0.0.0b1#n333 



So, this is a manifaestation of Admin ness not properly scoped
https://bugs.launchpad.net/keystone/+bug/968696

Note that it does not say admin on the project but rather admin 
anywhere which is endmic throughout opentstack, and something we are 
working to fix.


Policy rules that do not explicitly match scope for every token need to 
be rewritten to scope them properly.












With keystone v3 we could get requests with tokens scoped to parent 
projects that act upon child project resources for all APIs in general.


The first patch in the series [3] removes the top-level validation 
check for context.project_id != project_id in URL, since with v3 
it's a supported thing for a parent project to act on child project 
resources. (I don't think it's completely correct in that I think it 
would allow unrelated projects to act on one another)


Doing this fails the keypairs and security groups tempest tests [4] 
that verify that one project cannot create keypairs or security 
group rules in a different project.


Question: How can we handle project_id mismatch in a way that 
supports both keystone v2 and v3? Do we augment the check to fall 
back on checking if is parent of using keystone API if there's a 
project_id mismatch?


Question: Do we intend to, for example, allow creation of keypairs 
by a parent on behalf of child being that the private key is 
returned to the caller?


Basically, I feel stuck on these reviews because it appears to me 
that nova doesn't fully support identity v3 yet. From what I 
checked, there aren't yet Tempest jobs running against identity v3 
either.


Can anyone shed some light on this as I'm trying to see a way 
forward with the nested quotas reviews?


Thanks,
-melanie (irc: melwitt)


[1]https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z 


[2]https://review.openstack.org/#/c/103617/
[3]https://review.openstack.org/182140/
[4]http://logs.openstack.org/40/182140/12/check/check-tempest-dsvm-full/8e51c94/logs/testr_results.html.gz 





__ 


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


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




__ 


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

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






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

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

2015-07-23 Thread Evgeniy L

Hi,

The best option is to add new functionality to fuel2 only, but I
don't think that we can do that if there is not enough functionality
in fuel2, we should not ask user to switch between fuel and fuel2
to get some specific functionality.
Do we have some list of commands which is not covered in fuel2?
I'm just wondering how much time will it take to implement all
required commands in fuel2.

Thanks,

On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski 
skalinow...@mirantis.com wrote:

 Hi folks,

 For a some time in python-fuelclient we have two CLI apps: `fuel` and
 `fuel2`. It was done as an implementation of blueprint [1].
 Right now there is a situation where some new features are added just to
 old `fuel`, some to just `fuel2`, some to both. We cannot simply switch
 completely to new `fuel2` as it doesn't cover all old commands.
 As far as I remember there was no agreement how we should proceed with
 adding new things to python-fuelclient, so to keep all development for new
 commands I would like us to choose what will be our approach. There are 3
 ways to do it (with some pros and cons):

 A) Add new features only to old `fuel`.
 Pros:
  - Implement feature in one place
  - Almost all features are covered there
 Cons:
  - Someone will need to port this features to new `fuel2`
  - Issues that forced us to reimplement whole `fuel` as `fuel2`

 B) Add new features only to new `fuel2`
 Pros:
  - Implement feature in one place
  - No need to cope with issues in old `fuel` (like worse UX, etc.)
 Cons:
  - Not all features are covered by `fuel2` so user will need to switch
 between `fuel` and `fuel2`

 C) Add new features to both CLIs
 Pros:
  - User can choose which tool to use
  - No need to port feature later...
 Cons:
  - ...but it still doubles the work
  - We keep alive a tool that should be replaced (old `fuel`)


 Best,
 Sebastian

 [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client

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


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

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Oleg Gelbukh

Unless I am mistaken, it is possible to set most of the parameters
supported by Fuel menu as kernel boot parameters. Isn't it sufficient
replacement for fuelmenu for dev's purposes?

-Oleg

On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mmoses...@mirantis.com
wrote:

How much effort are we spending? I'm not so sure it's a major development
drain.

Since Fuel 6.0 dev cycle (Sept 2014) until now there have been 34
commits into Fuelmenu:
* New features/functionality: 12
* Bugfix: 15
* Other: 7 (version bumps, and commits without bug ID)

https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp

Am I alone in thinking it's not the best use of our development
resources to throw it away and replace it with a text file that is
edited by hand?

On Thu, Jul 23, 2015 at 3:33 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
Hello,

Here's my 2 cents on it.

I'm agree with Vladimir, vim + config files are enough, since Fuel is
not a product for housewives. It's a product for those who do not
hesitate to use Vim for soft configuration.

Thanks,
Igor

This topic comes up once a year only from Fuel Python developers
because they rarely use it and no dev cycles have been invested in
improving it.

The actual Fuel deployers use it and appreciate its validation and
wish to extend it.

I'd like to hear more feedback.

On Thu, Jul 23, 2015 at 2:23 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Dear colleagues,

What do you think of getting rid of fuelmenu and substituting it with
thoroughly commented text file + some validation + vim? The major pro
of
this is that text file is easier to extend and edit. Many people
prefer vim
UX instead of wandering through the semi-graphical interface. And it
is not
so hard to implement syntax and logic checking for the text file.

Please give your opinions about this.

Vladimir Kozhukalov

__
OpenStack Development Mailing List (not for 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] Need reviews of bp rpc-for-dse

2015-07-23 Thread Cheng, Yingxin

Tim and Masa,


Thanks very much for your invitation. I really wish I could come, but there is 
a visa problem.

I’m interested in Congress implementation and will join the sprint in remote.

Hope that my idea is helpful.


Yingxin


From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Thursday, July 23, 2015 9:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] Need reviews of bp rpc-for-dse

Hi Yingxin,

+1 to joining the sprint.  If you can't make the mid-cycle sprint in person, 
we're planning to have a remote option.  Keep in mind though that it will be 
harder to engage with everyone if you're remote.

We'll review your spec and get you feedback, but the purpose of the sprint (Aug 
6-7) is to decide and hopefully build the next generation of communication 
between the policy engines and the datasources.

Tim

On Thu, Jul 23, 2015 at 1:22 AM Masahito MUROI 
muroi.masah...@lab.ntt.co.jpmailto:muroi.masah...@lab.ntt.co.jp wrote:
Hi Yingxin,

I think moving Congress from dse to rpc is a good idea.

Congress team will discuss its scalability in mid cycle sprint[1], [2].
I guess using rpc is one of key item for congress to get the ability.
Why don't you join the meetup?

[1] https://wiki.openstack.org/wiki/Sprints/CongressLibertySprint
[2]
http://www.eventbrite.com/e/congress-liberty-midcycle-sprint-tickets-17654731778

best regard,
masa

On 2015/07/23 16:07, Cheng, Yingxin wrote:
 Hi all,


 I have some thoughts about congress dse improvement after having read the 
 code for several days.

 Please refer to 
 bp/rpc-for-dsehttps://blueprints.launchpad.net/congress/+spec/rpc-for-dse, 
 its idea is to implement RPC in deepsix. Congress can benefit from 
 lower-coupling between dse services. And the steps towards oslo-messaging 
 integration can be milder too.

 Eager to learn everything from Community. Anything wrong, please kindly point 
 it out.


 Thank you
 Yingxin



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



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


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

[openstack-dev] [openstack][nova] Streamlining of config options in nova

2015-07-23 Thread mhorban


Hi all,

During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options mixed
with source code in regular files.
From one side it can be convenient: to have module-encapsulated config
options. But problems appear when we need to use some config option in
different modules/packages.

If some option is registered in module X and module X imports module Y for
some reasons...
and in one day we need to import this option in module Y we will get 
exception

NoSuchOptError on import_opt in module Y.
Because of circular dependency.
To resolve it we can move registering of this option in Y module(in the
inappropriate place) or use other tricks.

I offer to create file options.py in each package and move all package's
config options and registration code there.
Such approach allows us to import any option in any place of nova without
problems.

Implementations of this refactoring can be done piece by piece where 
piece is

one package.

What is your opinion about this idea?

Marian

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

[openstack-dev] [oslo.serialization] Security or convenience?

2015-07-23 Thread Angus Lees

I'm working on a draft spec[1] for a new privilege separation mechanism
(oslo.privsep) and one of the reviewers mentioned oslo.serialization.  Yay.

My question is: From a quick glance over the current objects, it looks fine
atm - but is the intention that this library remain suitable for
security-sensitive purposes?

I guess I'm mostly concerned about things like PyYaml's !!python/object
feature or pickle's ability to serialise arbitrary objects - super useful
in normal use, just not in a security context.

 - Gus

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

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

2015-07-23 Thread Roman Vyalov

+1

On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:

 At the moment we have several core reviewers for the fuel-main project.

 Roman Vyalov is responsible for merging of infrastructure-related
 variables and for the lists of packages.
 I am responsible for merges in make system. And I have not so much time
 for digging into makefiles.

 Vladimir Kozhukalov is responsible for the makesystem for a long time. And
 now he works on reducing complexity of the system. I do not merge any
 single patch without his approval. It's time to give formal transfer of
 responsibility for the fuel-main to him. I nominate Vladimir to fuel-main
 core.

 Please reply with +1/-1.

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


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

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

2015-07-23 Thread Kevin L. Mitchell

On Thu, 2015-07-23 at 17:55 +0300, mhorban wrote:
 During development process in nova I faced with an issue related with config
 options. Now we have lists of config options and registering options mixed
 with source code in regular files.
  From one side it can be convenient: to have module-encapsulated config
 options. But problems appear when we need to use some config option in
 different modules/packages.
 
 If some option is registered in module X and module X imports module Y for
 some reasons...
 and in one day we need to import this option in module Y we will get 
 exception
 NoSuchOptError on import_opt in module Y.
 Because of circular dependency.
 To resolve it we can move registering of this option in Y module(in the
 inappropriate place) or use other tricks.

Isn't this use case what the import_opt() method of CONF is for?  The
description given in the docstring is:

Import a module and check that a given option is registered.

This is intended for use with global configuration objects
like cfg.CONF where modules commonly register options with
CONF at module load time. If one module requires an option
defined by another module it can use this method to explicitly
declare the dependency.

It's used all over the place in nova for this purpose, as far as I can
see.

 I offer to create file options.py in each package and move all package's
 config options and registration code there.
 Such approach allows us to import any option in any place of nova without
 problems.

The problem with this reorganization is that it moves the options from
the place where they're primarily intended to be used.  This could make
it harder to maintain, such as ensuring the help text is updated when
the code is.  If nova were a smaller code base, I think it would make
sense to reorganize in this fashion, but given how large nova actually
is…
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com
Rackspace


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

Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up a new CI system.

2015-07-23 Thread Asselin, Ramy

Are you running on 'master' nodes? I remember seeing an issue where with a 
recent version of Jenkins or a plugin where it doesn't execute jobs on the 
master node.
But when run on non-master jenkins slaves, it works fine.

-Original Message-
From: Tang Chen [mailto:tangc...@cn.fujitsu.com] 
Sent: Thursday, July 23, 2015 12:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [CI] Jenkins jobs are not executed when setting up 
a new CI system.

Hi, all

The Jenkins jobs submitted by zuul are always pending-Waiting for next 
available executor .

And Jenkins log shows the following:

Jul 24, 2015 11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl
submitFunction
WARNING:  Worker _exec-0 exception while executing function 
hudson.plugins.gearman.StartJobWorker
java.lang.RuntimeException: java.lang.RuntimeException: 
java.util.concurrent.CancellationException
at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:136)
at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:22)
at
hudson.plugins.gearman.MyGearmanWorkerImpl.submitFunction(MyGearmanWorkerImpl.java:590)
at
hudson.plugins.gearman.MyGearmanWorkerImpl.work(MyGearmanWorkerImpl.java:374)
at
hudson.plugins.gearman.AbstractWorkerThread.run(AbstractWorkerThread.java:166)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: 
java.util.concurrent.CancellationException
at
hudson.plugins.gearman.StartJobWorker.executeFunction(StartJobWorker.java:116)
at
org.gearman.worker.AbstractGearmanFunction.call(AbstractGearmanFunction.java:125)
... 5 more
Caused by: java.util.concurrent.CancellationException
at hudson.remoting.AsyncFutureImpl.get(AsyncFutureImpl.java:77)
at
hudson.plugins.gearman.StartJobWorker.safeExecuteFunction(StartJobWorker.java:196)
at
hudson.plugins.gearman.StartJobWorker.executeFunction(StartJobWorker.java:114)
... 6 more

Jul 24, 2015 11:09:04 AM hudson.plugins.gearman.MyGearmanWorkerImpl work
INFO:  Worker _exec-0 sending initial grab job Jul 24, 2015 11:09:04 AM 
hudson.plugins.gearman.MyGearmanWorkerImpl
handleSessionEvent
INFO:  Worker _exec-1 received unique job assignment Jul 24, 2015 11:09:04 
AM hudson.plugins.gearman.MyGearmanWorkerImpl work
INFO:  Worker _exec-1 executing function Jul 24, 2015 11:09:04 AM 
hudson.plugins.gearman.StartJobWorker
safeExecuteFunction
INFO:  Worker _exec-1 scheduling devstack-vm-test build #14 on with UUID 
83d4fd10c1ad4f1ead51beb2adf23ccd and build params
[(StringParameterValue) BASE_LOG_PATH='03/204803/1',
(StringParameterValue) ZUUL_PIPELINE='check', (StringParameterValue) 
ZUUL_UUID='83d4fd10c1ad4f1ead51beb2adf23ccd', (StringParameterValue) 
LOG_PATH='03/204803/1/check/devstack-vm-test/83d4fd1',
(StringParameterValue) ZUUL_CHANGE_IDS='204803,1',
(StringParameterValue) ZUUL_PATCHSET='1', (StringParameterValue) 
ZUUL_BRANCH='master', (StringParameterValue) 
ZUUL_REF='refs/zuul/master/Z07d022076a68448d842bd1a47dd42e19',
(StringParameterValue)
ZUUL_COMMIT='174cac545549f086e07f32edbe34b70c4155a7fc',
(StringParameterValue) ZUUL_URL='http://10.124.196.205/p/',
(StringParameterValue) ZUUL_CHANGE='204803', (StringParameterValue) 
ZUUL_CHANGES='openstack-dev/sandbox:master:refs/changes/03/204803/1',
(StringParameterValue) ZUUL_PROJECT='openstack-dev/sandbox']

It seems that Gearman doesn't work properly.

Do you guys have any idea of this ?

Thanks.

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

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

[openstack-dev] [glance][api] Response when a illegal body is sent

2015-07-23 Thread Bunting, Niall

Hi,

Currently when a body is passed to an API operation that explicitly does not 
allow bodies Glance throws a 500.

Such as in this bug report: https://bugs.launchpad.net/glance/+bug/1475647 This 
is an example of a GET however this also applies to other requests.

What should Glance do rather than throwing a 500, should it return a 400 as the 
user provided an illegal body or should Glance ignore the body and continue?

Regards,
Niall

__
OpenStack Development Mailing List (not for 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][L3] Representing a networks connected by routers

2015-07-23 Thread Carl Baldwin

On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton blak...@gmail.com wrote:
 The issue with the availability zone solution is that we now force
 availability zones in Nova to be constrained to network configuration. In
 the L3 ToR/no overlay configuration, this means every rack is its own
 availability zone. This is pretty annoying for users to deal with because
 they have to choose from potentially hundreds of availability zones and it
 rules out making AZs based on other things (e.g.  current phase, cooling
 systems, etc).

 I may be misunderstanding and you could be suggesting to not expose this
 availability zone to the end user and only make it available to the
 scheduler. However, this defeats one of the purposes of availability zones
 which is to let users select different AZs to spread their instances across
 failure domains.

I was actually talking with some guys at dinner during the Nova
mid-cycle last night (Andrew ??, Robert Collins, Dan Smith, probably
others I can't remember) about the relationship of these network
segments to AZs and cells.  I think we were all in agreement that we
can't confine segments to AZs or cells nor the other way around.

Carl

__
OpenStack Development Mailing List (not for 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] why do we gate tempest using q-vpn not q-l3?

2015-07-23 Thread Armando M.

On 23 July 2015 at 05:25, Ihar Hrachyshka ihrac...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi all,

 I've stumbled on this one. It turns out we gate neutron against
 openstack installation that runs vpn-agent instead of l3-agent [1]. Is
 it really what we want to do? I would expect that gate validates l3
 agent as is, as is usually found on usual installations that do not
 need vpn connections.


We run with q-fwaas as well (which then lead to [1] as command line for the
L3 agent execution). Same can be said for fwaas, no?

[1] + setsid /usr/local/bin/neutron-vpn-agent --config-file
/etc/neutron/neutron.conf --config-file=/etc/neutron/l3_agent.ini
--config-file=/etc/neutron/vpn_agent.ini --config-file
/etc/neutron/fwaas_driver.ini


 Or is it the neat way we make sure we don't break vpn-agent?


The tempest-full test suite used to exercise network core capabilities as
well as advanced services (with test_vpnaas_extensions and
test_fwaas_extensions), now that it doesn't anymore [2] we could drop both,
as coverage is ensured by the neutron-dsvm-api job.

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



 [1]:
 https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/test-f
 eatures.sh#n21

 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVsN1RAAoJEC5aWaUY1u57eZ0IAI9oJIikbvD5dxGPoB7wm7mX
 9OE583CAjn+hGUIMGa0kpVSBeDQmkQdp92ginFOo1lvXQZVT30OCOJau5YVoGE77
 Nl1d9TX6xO8vDkBNT5A69vHfZGxjL620+HvOHjupTYimqWiilj6fu0oUge2DNtI7
 do8TgL7SpDx31z9pF70zxqfHbARXq3HOb/AMfTz8jBRcnZmuvOQLt4Q/Xri6KFUw
 uW8XaEZ+3xJYsaFsWna8YIEQY/R4TDqnyStGvRqzX9CGRDkzc/0gWalBSAkXewdQ
 sOwN4MhhxJcWMXRVwPp+auvBOKQJ8Bq5uIR0WRIDhAaUtDNHstDefFnCBzmX8nc=
 =kxs2
 -END PGP SIGNATURE-

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

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

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Nick Chase




On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn 
mmoses...@mirantis.com mailto:mmoses...@mirantis.com wrote:


Here's a relic of what users used to have to configure by
hand:

https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp

Am I alone in thinking it's not the best use of our development
resources to throw it away and replace it with a text file that is
edited by hand?



Please, please, please, I'm having PTSD just remembering that @#$%@#%$ 
file.  I think I was able to successfully deploy without major 
engineering help about 2% of the time.  We absolutely, positively, MUST 
maintain the validation.


Just because the people installing OpenStack are generally not afraid to 
edit config files doesn't mean that we should be making them do it.


 Nick
__
OpenStack Development Mailing List (not for 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] Need reviews of bp rpc-for-dse

2015-07-23 Thread Tim Hinrichs

Hi Yingxin,

We definitely want details for what you have in mind.  In case you haven't
done this before, we write a 'spec' to explain the details.  Here's some
info on how to do that.

https://wiki.openstack.org/wiki/Congress#How_To_Propose_a_New_Feature

Tim



On Thu, Jul 23, 2015 at 12:13 AM Cheng, Yingxin yingxin.ch...@intel.com
wrote:

  Hi all,





 I have some thoughts about congress dse improvement after having read the
 code for several days.



 Please refer to bp/rpc-for-dse
 https://blueprints.launchpad.net/congress/+spec/rpc-for-dse, its idea
 is to implement RPC in deepsix. Congress can benefit from lower-coupling
 between dse services. And the steps towards oslo-messaging integration can
 be milder too.



 Eager to learn everything from Community. Anything wrong, please kindly
 point it out.





 Thank you

 Yingxin

 __
 OpenStack Development Mailing List (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][Kuryr][kolla] - Bringing Dockers networking to Neutron

2015-07-23 Thread Steven Dake (stdake)

Gal,

I’m not clear exactly what you plan to do with regards to building docker 
containers for Neutron, but the Kolla project has developed both linuxbridge 
and ovs agents as well as a complete running Neutron system inside container 
technology.  We can launch it AIO with docker-compose, or alternatively it can 
be launched AIO or multinode with Ansible.  Note we have a complete OpenStack 
implementation, not just Neutron.

We would welcome additional driver support using the standard OpenStack gerrit 
workflow.

https://github.com/stackforge/kolla/tree/master/docker/centos/binary/neutron

Note we are also in the process of adding build from source to our tree here:

https://github.com/stackforge/kolla/tree/master/docker/centos/source/neutron

For further background on Kolla, check out our wiki page:

https://wiki.openstack.org/wiki/Kolla

Best wishes,
-steve

From: Gal Sagie gal.sa...@gmail.commailto:gal.sa...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, July 22, 2015 at 9:28 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Eran Gampel 
eran.gam...@toganetworks.commailto:eran.gam...@toganetworks.com, Antoni 
Segura Puimedon t...@midokura.commailto:t...@midokura.com, Irena Berezovsky 
ir...@midokura.commailto:ir...@midokura.com
Subject: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to 
Neutron


Hello Everyone,

Project Kuryr is now officially part of Neutron's big tent.
Kuryr is aimed to be used as a generic docker remote driver that connects 
docker to Neutron API's
and provide containerised images for the common Neutron plugins.
We also plan on providing common additional networking services API's from 
other sub projects
in the Neutron big tent.

We hope to get everyone on board with this project and leverage this joint 
effort for the many different solutions out there (instead of everyone 
re-inventing the wheel for each different project).

We want to start doing a weekly IRC meeting to coordinate the different 
requierments and
tasks, so anyone that is interested to participate please share your time 
preference
and we will try to find the best time for the majority.

Remember we have people in Europe, Tokyo and US, so we won't be able to find 
time that fits
everyone.

The currently proposed time is  Wedensday at 16:00 UTC

Please reply with your suggested time/day,
Hope to see you all, we have an interesting and important project ahead of us

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

[openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

2015-07-23 Thread Dmitry Pyzhov

At the moment we have several core reviewers for the fuel-main project.

Roman Vyalov is responsible for merging of infrastructure-related variables
and for the lists of packages.
I am responsible for merges in make system. And I have not so much time for
digging into makefiles.

Vladimir Kozhukalov is responsible for the makesystem for a long time. And
now he works on reducing complexity of the system. I do not merge any
single patch without his approval. It's time to give formal transfer of
responsibility for the fuel-main to him. I nominate Vladimir to fuel-main
core.

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

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Matthew Mosesohn

Oleg, those parameters are no longer documented (because there was no
validation) and are absent from the Fuel User Guide. They are,
however, still used by fuel-qa scripts.

On Thu, Jul 23, 2015 at 5:26 PM, Oleg Gelbukh ogelb...@mirantis.com wrote:
Unless I am mistaken, it is possible to set most of the parameters supported
by Fuel menu as kernel boot parameters. Isn't it sufficient replacement for
fuelmenu for dev's purposes?

-Oleg

On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mmoses...@mirantis.com
wrote:

How much effort are we spending? I'm not so sure it's a major development
drain.

Since Fuel 6.0 dev cycle (Sept 2014) until now there have been 34
commits into Fuelmenu:
* New features/functionality: 12
* Bugfix: 15
* Other: 7 (version bumps, and commits without bug ID)

https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp

Am I alone in thinking it's not the best use of our development
resources to throw it away and replace it with a text file that is
edited by hand?

On Thu, Jul 23, 2015 at 3:33 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
Hello,

Here's my 2 cents on it.

I'm agree with Vladimir, vim + config files are enough, since Fuel is
not a product for housewives. It's a product for those who do not
hesitate to use Vim for soft configuration.

Thanks,
Igor

This topic comes up once a year only from Fuel Python developers
because they rarely use it and no dev cycles have been invested in
improving it.

The actual Fuel deployers use it and appreciate its validation and
wish to extend it.

I'd like to hear more feedback.

On Thu, Jul 23, 2015 at 2:23 PM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
Dear colleagues,

What do you think of getting rid of fuelmenu and substituting it with
thoroughly commented text file + some validation + vim? The major pro
of
this is that text file is easier to extend and edit. Many people
prefer vim
UX instead of wandering through the semi-graphical interface. And it
is not
so hard to implement syntax and logic checking for the text file.

Please give your opinions about this.

Vladimir Kozhukalov

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

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

2015-07-23 Thread Igor Kalnitsky

+1.

On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
 At the moment we have several core reviewers for the fuel-main project.

 Roman Vyalov is responsible for merging of infrastructure-related variables
 and for the lists of packages.
 I am responsible for merges in make system. And I have not so much time for
 digging into makefiles.

 Vladimir Kozhukalov is responsible for the makesystem for a long time. And
 now he works on reducing complexity of the system. I do not merge any single
 patch without his approval. It's time to give formal transfer of
 responsibility for the fuel-main to him. I nominate Vladimir to fuel-main
 core.

 Please reply with +1/-1.

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


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

[openstack-dev] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Vladimir Kozhukalov

Dear colleagues,

What do you think of getting rid of fuelmenu and substituting it with
thoroughly commented text file + some validation + vim? The major pro of
this is that text file is easier to extend and edit. Many people prefer vim
UX instead of wandering through the semi-graphical interface. And it is not
so hard to implement syntax and logic checking for the text file.

Please give your opinions about this.

Vladimir Kozhukalov
__
OpenStack Development Mailing List (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] [Rally][Meeting][Agenda]

2015-07-23 Thread Roman Vasilets

Hi, its a friendly reminder that if you what to discuss some topics at
Rally meetings, please add you topic to our Meeting agenda
https://wiki.openstack.org/wiki/Meetings/Rally#Agenda. Don't forget to
specify by whom led this topic. Add some information about topic(links,
etc.) Thank you for your attention.

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

Re: [openstack-dev] [glance][api] Response when a illegal body is sent

2015-07-23 Thread Jay Pipes


On 07/23/2015 10:53 AM, Bunting, Niall wrote:

Hi,

Currently when a body is passed to an API operation that explicitly
does not allow bodies Glance throws a 500.

Such as in this bug report:
https://bugs.launchpad.net/glance/+bug/1475647 This is an example of
a GET however this also applies to other requests.

What should Glance do rather than throwing a 500, should it return a
400 as the user provided an illegal body


Yep, this.

Best,
-jay

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

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

2015-07-23 Thread Stanislaw Bogatkin

Hi,

can we just add all needed functionality from old fuel client that fuel2
needs, then say that old fuel-client is deprecated now and will not support
some new features, then add new features to fuel2 only? It seems like best
way for me, cause with this approach:
1. Clients will can use only one version of client (new one) w/o switching
between 2 clients with different syntax
2. We won't have to add new features to two clients.

On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 The best option is to add new functionality to fuel2 only, but I
 don't think that we can do that if there is not enough functionality
 in fuel2, we should not ask user to switch between fuel and fuel2
 to get some specific functionality.
 Do we have some list of commands which is not covered in fuel2?
 I'm just wondering how much time will it take to implement all
 required commands in fuel2.

 Thanks,

 On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski 
 skalinow...@mirantis.com wrote:

 Hi folks,

 For a some time in python-fuelclient we have two CLI apps: `fuel` and
 `fuel2`. It was done as an implementation of blueprint [1].
 Right now there is a situation where some new features are added just to
 old `fuel`, some to just `fuel2`, some to both. We cannot simply switch
 completely to new `fuel2` as it doesn't cover all old commands.
 As far as I remember there was no agreement how we should proceed with
 adding new things to python-fuelclient, so to keep all development for new
 commands I would like us to choose what will be our approach. There are 3
 ways to do it (with some pros and cons):

 A) Add new features only to old `fuel`.
 Pros:
  - Implement feature in one place
  - Almost all features are covered there
 Cons:
  - Someone will need to port this features to new `fuel2`
  - Issues that forced us to reimplement whole `fuel` as `fuel2`

 B) Add new features only to new `fuel2`
 Pros:
  - Implement feature in one place
  - No need to cope with issues in old `fuel` (like worse UX, etc.)
 Cons:
  - Not all features are covered by `fuel2` so user will need to switch
 between `fuel` and `fuel2`

 C) Add new features to both CLIs
 Pros:
  - User can choose which tool to use
  - No need to port feature later...
 Cons:
  - ...but it still doubles the work
  - We keep alive a tool that should be replaced (old `fuel`)


 Best,
 Sebastian

 [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client

 __
 OpenStack Development Mailing List (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][L3] Representing a networks connected by routers

2015-07-23 Thread Carl Baldwin

On Tue, Jul 21, 2015 at 8:41 AM, Salvatore Orlando
salv.orla...@gmail.com wrote:
 It is however important to ensure services like DHCP keep working as usual.
 Treating segments as logical networks in their own right is the simples
 solution to achieve this imho.

Agreed.

 While the logical model and workflow you describe here makes sense, I have
 the impression that:
 1) The front network is not a neutron logical network. Because it does not
 really behave like a network, with the only exception that you can pass its
 id to the nova API. To reinforce this consider that basically the front
 network has no ports.

One thing that I have been trying to figure out how to do is to take
the external network model that we currently have and scale it without
really changing the way the user interacts with it to get a floating
IP and associate it with their instances port.  I've seen external
networks that span several AZs to reach thousands of hosts.  To the
end user, it is convenient to see it as one pool of addresses for
their floating IPs which can be associated with any port anywhere.

But, there are problems with doing this as a single L2 broadcast
domain.  I'd like to map this external network to the same kind of
routed segments infrastructure that the operators are asking for.  I
was hoping to do so without changing what the end user sees through
the API.

In my use case, the front network is a place to hang the floating IP subnet.

GoDaddy has done something like this but they did it a bit differently
without NAT.  However, they also use the external or front network
as a place to hang the floating IP subnet.

My model may not be the best way to do this.  I'm happy to go back to
the drawing board.  However, I'd like for people to understand that I
want an address block that is not confined to a segment.  I'd like to
use it for floating IPs to be associated with any port on any of the
segments.  Today, we associate subnets with networks.  That was part
of the motivation for modeling this as a network.

 2) from a topological perspective the front network kind of behaves like
 an external network; but it isn't. The front network is not really a common
 gateway for all backing networks, more like a label which is attached to the
 router which interconnects all the backing networks.

I don't understand well enough to comment.

 3) more on topology. How can we know that all these segments will always be
 connected by a single logical router? Using static router (or If one day BGP
 will be a thing), it is already possible to implement multi-segments
 networks with L3 connectivity using multiple logical routers, isn't it?

If there are multiple logical routers connected together couldn't you
consider the overall routing effect of those routers as a single
router if the details aren't important?

 4) Point #5 is making assumptions on network aware scheduling. I am not sure
 we already have the ability to inform the nova scheduler to deploy an
 instance on a host where a give network is available.

This is something we need to continue to discuss.

 5) I think that I would treat the front network as a network group or
 cluster. I noticed the term subnet cluster is used in the etherpad. I
 find this term appropriate because it seems to me that in this scenario the
 final user does not care at all about the network intended as a L2 segment.
 6) It seems one of the purposes of using backing networks is to identify an
 address block for the ports being created. But then how would that play with
 mobile address blocks? From an instance workflow perspective, should
 instances be associated with one or more address blocks at boot time?
 7) What happens is a user attaches a router to a backing network and connect
 that router to an external network? Does that becomes a gateway for all
 backing networks or just for that network? And would the workflow be for
 uplinking a front network to an external network?

The user's router is just a gateway for the user's private network.

I imagine that a front network could itself be an external network.

  This proposal offers a clear separation between the statically bound
  and the mobile address blocks by associating the former with the
  backing networks and the latter with the front network.  The mobile
  addresses are modeled just like floating IPs are today but are
  implemented by some plugin code (possibly without NAT).

 Couldn't the mobile addresses be _exactly_ like floating IPs already
 are?  Why is anything different from floating IPs needed here?

I don't think they are.  Given our current model, floating ips come
from subnets associated with an external network.  That's why I
modeled the front network as such, so that the floating IP model would
look very much like it does today.

 
  This proposal also provides some advantages for integrating dynamic
  routing.  Since each backing network will, by necessity, have a
  corresponding router in the infrastructure, the

[openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature

2015-07-23 Thread Julia Aranovich

Team,

I would like to request an exception from the Feature Freeze for CLI
changes of working with custom node labels added to fuelclient (fuel2) [1].
UI and Nailgun parts of the story are already merged [2].

There CLI request is being actively reviewed, the base flow is accepted.
There are minimal risks here since the changes added to fuel2 version.

Please, respond if you have any questions or concerns related to this
request.

Thanks in advance,
Julia

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

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

2015-07-23 Thread Vladimir Kozhukalov

-1 for using kernel parameters for configuring the whole master node
installation. User should be able to edit configuration and then re-deploy
the master node. I have no idea what would UX look like if we used kernel
paramenters.

Vladimir Kozhukalov

On Thu, Jul 23, 2015 at 7:49 PM, Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 The topic is NOT 'get rid of validation' but rather 'get rid of
 semi-graphical ncurses based interface'. It is not so hard to adopt every
 piece of validation we currently have in fuelmenu and implement even more
 including syntax validation using, for example, PLY and logic validation.
 My idea is to switch from ncurses to plain text file (thoroughly
 commented), because it so easy to add new parameters or remove those we
 don't need any more.




 Vladimir Kozhukalov

 On Thu, Jul 23, 2015 at 6:17 PM, Nick Chase nch...@mirantis.com wrote:



  On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn 
 mmoses...@mirantis.commmoses...@mirantis.com wrote:

 Here's a relic of what users used to have to configure by
 hand:

 https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp

 Am I alone in thinking it's not the best use of our development
 resources to throw it away and replace it with a text file that is
 edited by hand?


 Please, please, please, I'm having PTSD just remembering that @#$%@#%$
 file.  I think I was able to successfully deploy without major engineering
 help about 2% of the time.  We absolutely, positively, MUST maintain the
 validation.

 Just because the people installing OpenStack are generally not afraid to
 edit config files doesn't mean that we should be making them do it.

  Nick

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



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

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

2015-07-23 Thread Michael Still

In fact, I did an example of what I thought it would look like already:

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

I welcome discussion on this, especially from people who couldn't make
it to the mid-cycle. Its up to y'all if you do that on this thread or
in that review.

Michael

On Thu, Jul 23, 2015 at 11:41 AM, Sean Dague s...@dague.net wrote:
 On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
 Hi all,

 FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]

 Putting all Nova options into one big file is probably not a good
 idea, still we could consider storing those per-package (per backend,
 per driver, etc), rather than per Python module to reduce the number
 of possible circular imports when using import_opt() helper.

 Thanks,
 Roman

 [0] https://github.com/openstack/oslo.db/blob/master/oslo_db/options.py

 Actually, we just happened to be discussing this at the Nova meetup this
 morning. And the general consensus was the opposite. It would be better
 to collect all the config options in one file, especially if we are
 going to expand the help (which we would like to do). Exceptions are
 done that way in Nova.

 Michael Still is going to propose some initial patches to get this
 rolling. We don't expect this to be a big bang, but in chunks as the
 help is being improved.

 -Sean

 --
 Sean Dague
 http://dague.net


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




-- 
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] [cross-project] Admin ness not properly scoped

2015-07-23 Thread melanie witt

On Jul 23, 2015, at 7:35, Adam Young ayo...@redhat.com wrote:

 What this means is the if a user is assigned admin on any project, they are 
 assigned admin for everything.
 
 Fixing this is going to require a change to how we write policy.
 
 Each policy rule needs to have two parts:
 
 1.  Match the scoped of the token (project for everything that is not 
 Keystone, project or domain for Keystone).
 
 2.  Match the role.

Thanks for bringing this up. If I understand correctly, you're saying we can 
fix this by modifying policy.json alone, right? There aren't any code changes 
required?

So far, for me it has worked fine for admin role to grant admin everywhere 
for the system administrators (no one else has admin role). But with the 
prospect of nested quota in nova, I think we would have a new rule for quota 
update that is, for example:

quota_admin_rule: role:quota_admin and project_id:%(project_id)s
admin_or_quota_admin: role:admin or rule:quota_admin_rule

compute_extension:quotas:update: rule:admin_or_quota_admin,
compute_extension:quotas:delete: rule:admin_or_quota_admin,
os_compute_api:os-quota-sets:update: rule:admin_or_quota_admin,
os_compute_api:os-quota-sets:delete: rule:admin_or_quota_admin,
os_compute_api:os-quota-sets:detail: rule:admin_or_quota_admin,

if I want system administrators and designated quota administrators of a 
project to be able to update quota. In keystone the quota admins will have the 
role quota_admin only in their projects.

Is that an example of the right way to scope admin in your view?

-melanie (irc: melwitt)







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

Re: [openstack-dev] [horizon] Minimum Unit Test Coverage

2015-07-23 Thread Michael Krotscheck

+1 on coverage of any kind.

From a tooling perspective, are you thinking istanbul?

From an infra perspective, are you thinking a separate job, or to have it
integrated in with npm run test? FYI- istanbul wraps the unit test
invocation, e.g. 'istanbul karma start ./karma.config.js' or something
similar.

100% code coverage is ambitious. Let's get the tool selected and working
first.

Michael

On Wed, Jul 22, 2015 at 11:57 AM Rajat Vig raj...@thoughtworks.com wrote:

 Hi Rob

 I agree. Enforcing a minimum level of coverage as a start is awesome.

 I must add though keeping it at 100% and breaking the build has almost
 never worked in practice for me.
 Keeping a slightly lower level ~98% is slightly more pragmatic.
 Also, the currently low coverages will have to be addressed as well.
 Is there a blueprint that can be created to tackle it?

 -Rajat


 On Wed, Jul 22, 2015 at 6:33 AM, Rob Cresswell (rcresswe) 
 rcres...@cisco.com wrote:

  Hi all,

  As far as I’m aware, we don’t currently enforce any minimum unit test
 coverage, despite Karma generating reports. I think as part of the review
 guidelines, it would be useful to set a minimum. Since Karma’s detection is
 fairly relaxed, I’d put it at 100% on the automated reports.

  I think the biggest drawback is that the tests may not be “valuable”,
 but rather just meet the minimum requirements. I understand this sentiment,
 but I think that “less valuable” is better then “not present” and it gives
 reviewers a clear line to +1/ -1 a patch. Furthermore, it encourages the
 unit tests to be written in the first place, so that reviewers can then ask
 for improvements, rather than miss them.

  Rob

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

1 2 >

1 - 100 of 162 matches

Mail list logo