Re: [openstack-dev] [Nova][libvirt]Could not create tap interface in ovs bridge

[Phaneendra Manda]

Hi Arturo,

This is because the OVS we installed have not replaced the existing OVS.
This problem was solved by uninstalling the OVS first and then install the
new OVS version.

-- 
Thanks & regards,
Phaneendra Manda.

On Mon, Jul 11, 2016 at 10:01 PM, amll  wrote:

> Hi,
>
> I think I am having the same problem, did you manage to solve it?
>
> Thanks in advance,
>
> Arturo Mayoral.
>
> El 10/01/16 a las 13:28, manda phaneendra escribió:
>
> Hi,
> When i am spawning a new VM, there is an error in neutron conductor
> "error: Unable to add port tapc3b3f80b-ee to OVS bridge br-int"
>
> When the issue is analyzed further, have seen error in libvirt logs,
> "libvirt:  error : cannot execute binary ovs-vsctl: Permission denied"
> and
>  error : virNetDevOpenvswitchAddPort:155 : internal error: Unable to add
> port tap1ffb7f48-81 to OVS bridge br-int
>
> After installing the OVS patch, ovs-vsctl is installed in /usr/local/bin
>
> Please help me how to solve this problem.
>
> --
> Thanks & regards,
> Phaneendra Manda.
> ph: +91 9972 622 741
> Email:  mphaneen...@gmail.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] next notification subteam meeting

[Balázs Gibizer]

Hi, 

The next notification subteam meeting will be held on 2016.07.12 17:00 UTC [1] 
on #openstack-meeting-4.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160712T17

__
OpenStack Development Mailing List (not for 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] why do we need setting network driver per node?

[Sukhdev Kapur]

Hi Devananda,

This is a good summary. I think the proposal makes a lot of sense.

We need to agree to this as soon as possible so that we can get the Ironic
patches merged by this Friday - to meet the timelines.

Can you set up the number for the voice call so that we can all dial in,
discuss, if further discussion is needed, and get this closed off.
Ideally, we can work to approve/modify the patches while we are all on the
call.

thoughts?

-Sukhdev


On Mon, Jul 11, 2016 at 3:03 PM, Sam Betts (sambetts) 
wrote:

> Thanks for following up with this Devananda, I¹ve left a couple of
> corrections to my proposal inline, unfortunately IRC isn¹t the best for
> putting ideas this complex across :)
>
> Sam
>
> On 11/07/2016 21:57, "Devananda van der Veen" 
> wrote:
>
> >We spent the majority of today's weekly IRC meeting [1] discussing the
> >finer
> >points of this question. I agreed to post a summary of those to the list
> >(it's
> >below the break).
> >
> >tldr;
> >
> >* we don't know if network_interface should behave like other hardware
> >interfaces, but...
> >* we need to come to an agreement on it this week, so we can proceed with
> >the
> >network integration work.
> >
> >
> >Background:
> >
> >- As proposed in the driver composition reform spec [2], each
> >hardware_type
> >class (eg, ilo_gen8) shall specify a set of allowable interface
> >implementations
> >(eg, noop, flat, neutron are all network_interfaces) for each interface
> >type
> >(eg, deploy_interface, power_interface, network_interface).
> >- A hardware_type shall also indicate a default for each interface_type.
> >(**
> >this is what we debated ** )
> >- There is no CONF option to specify a global default for each
> >interface_type
> >(eg, there is no CONF.default_power_interface setting, because it varies
> >by
> >hardware_type)
> >- There will be a CONF option to enable ("allow") hardware classes and
> >CONF
> >options to enable ("allow") interface classes.
> >
> >
> >Points raised in the meeting today:
> >
> >- in "most" cases, network_interface will depend more on the environment
> >than a
> >specific Node's hardware or out-of-band management device
> >
> >- in "exceptional" cases, a Node may only support specific
> >network_interfaces
> >(eg, certain Cisco hardware, a Blade enclosure)
> >
> >- maybe hardware_type should specify a default for some interfaces but not
> >others? Example:
> >  - the ilo_gen8 hardware class should specify power, deploy, and
> >management
> >interface defaults to ilo-specific interface classes
> >  - but the operator should set the network interface as appropriate to
> >their
> >environment
> >
> >- if we were to force the operator to specify Node.network_interface (but
> >not
> >any other interface) when enrolling every node, this will be apoor
> >experience.
> >
> >- we should add a global CONF setting to allow operators to set a default
> >network interface for their environment.
> >
> >- words are hard. we shouldn't call network_interface an "interface" if it
> >behaves differently than other interfaces.
> >
> >- we have two "types" of interfaces on drivers: hardware-types and
> >environment-types. maybe we should treat them differently?
> >
> >- other things also depend on the environment (rather than the Node's
> >hardware
> >or BMC) such as deploy_interface and volume_interface.
> >
> >
> >There was a proposal from sambetts towards the end of the meeting, which
> >I've
> >edited for clarity (please correct if I misunderstood any of your
> >points). This
> >seems to capture/address most of the points above and proposes a way
> >forward,
> >while keeping within the intent of our driver composition reform spec. It
> >was
> >the only clear suggestion during the meeting.
> >
> >- in-tree hardware_types declare supported_network_interfaces to be empty
> >[4]
> >and declare no default_network_interface
>
> Your suggestion in [4] is what I meant, but I couldn¹t type fast enough in
> the meeting. In-tree hardware_types will list support for
> network_interfaces according to their vendor¹s preference (I expect for
> most/all drivers that will at least be [noop, flat, neutron]). And if in
> the future as a vendor I want to, for example, push my hardware specific
> network interface in tree, then my Cisco drivers will gain an additional
> network_interface in their supported_network_interfaces list, [noop, flat,
> neutron, cisco].
>
> >- we add a CONF option for default_network_interface, with a sane default
> >value
> >- this CONF option is validated on conductor load to be supported by all
> >loaded
> >hardware_types, and the conductor refuses to start if this CONF option is
> >set to
> >a value not supported by one or more enabled_hardware_types
> >- if a(n out of tree) hardware_type declares a default_network_interface,
> >this
> >will take precedence over the CONF option
>
> I believe that all hardware_types should specify their supported network
> interfaces, 

Re: [openstack-dev] [OpenStack-Ansible] Splitting out generic testing components

[Carter, Kevin]

+1 I think this is a great initiative and should go a long way to
unifying and improving our tests within the roles. I too would love to
see this moved to the namespace so that folks can begin working on and
reviewing changes gerrit.

@Jesse, assuming everything is on the up and up, what are the next
steps to getting this setup in our project-config?

--

Kevin Carter
IRC: cloudnull

On Fri, Jul 8, 2016 at 9:18 AM, Truman, Travis
 wrote:
> Nice work Andy. I’m strongly in favor of getting the central test repo into
> Gerrit for broader reviews and once done, getting one or two patches up with
> roles making use of it.
>
> - Travis Truman
>
> From: Andy McCrae 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Friday, June 3, 2016 at 11:41 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [OpenStack-Ansible] Splitting out generic testing
> components
>
> TL;DR We're doing a PoC to split out common testing plays/vars into a
> generic repository, for the purposes of making in-role testing more uniform
> and generic. Looking for feedback, comments, informal reviews, ideas etc!
> https://github.com/andymcc/openstack-ansible-testing-core (Includes a simple
> README)
>
> We now have a lot of duplication after moving to a single role per
> repository structure with specific testing per role. For example, almost all
> repositories require Galera/Rabbit/Keystone in order to deploy testing
> successfully. This has led to a scenario where each repository essentially
> carries the same deployment code.
>
>
> Aims:
> - The primary aim of extracting the testing infrastructure into a single
> repository is to reduce the cases where a simple change is needed, which
> dominoes, causing a patch to each of 15 repositories. Instead, a change to
> the uniform testing repository would resolve the issue for all other
> repository's testing.
> - In the future, we are looking to deploy scenario testing. For example, we
> may want to test glance with a swift backend, or keystone with memcache. If
> the testing play to deploy swift is already in a uniform repository, the
> changes required to get glance testing enabled for that use case would be
> minimal.
> - This allows new projects to consume existing structure/playbooks to deploy
> common components and vars, which should simplify the manner in which new
> openstack-ansible projects set up their testing.
>
>
> Steps taken so far:
> - The deployment plays for each project have been split out into the
> separate testing role.
> - Each role only carries a specific "Test project" play.
> - The test playbooks have been made generic so it uses the inventory
> specified per repository (defining what hosts/roles there are).
> - The test-vars have been put in the testing-repository and moved out of the
> generic role.
> - An override file has been created for each project and included using "-e"
> (the highest precedence) but at present, of the 4 projects converted the
> maximum number of overrides used is 2, so these overrides are minimal.
> - Adjustments to tox.ini and var files references have been made to use the
> new repository.
>
>
> Further work to look into:
> - It may be worth looking into making the tox.ini more generic, if we were
> to make a sweeping change that impacts on tox.ini we would still need to do
> changes to each repository. (I am not sure on how feasible this is though)
>
>
> Raised concerns:
> - This creates a situation where a change may require me to make a change to
> the central testing repository before changing the role repository. For
> example, in order to get the generic testing for a keystone change I would
> have to change the testing repository in advance, and then change the
> keystone repository. Or override the var, adjust the testing repo and then
> remove the keystone override.
> - Changes to the testing-repo can cause all other repo tests (aside from the
> overarching openstack-ansible repository) from breaking.
>
>
> Where to find the PoC, what next?
>
> The repository can be found here:
> https://github.com/andymcc/openstack-ansible-testing-core
>
> This is a proof of concept so in no way is it considered complete or
> perfect, we are asking for more eyes on this; test it, let us know what you
> like/do not like/want changed/additional ideas to improve.
>
> Thanks!
>
> Andy
> irc: andymccr
>
>
> __
> OpenStack Development Mailing List (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: 

Re: [openstack-dev] The future of OpenStack documentation

[Matt Kassawara]

Inline...

On Sun, Jul 10, 2016 at 5:22 PM, Lana Brindley 
wrote:

> On 09/07/16 07:02, Matt Kassawara wrote:
> > Currently, OpenStack provides central documentation (primarily in the
> openstack-manuals repository) for operators and users. The single location
> and consistent structure eases audiences of various technical expertise
> into OpenStack, typically operators and users rather than developers.
> Although I'm not a fan of the word "product", increasingly less technical
> audiences are learning about OpenStack and tend to compare it with other
> cloud infrastructure products. Such audiences expect a coherent, relatively
> mature product to easily evaluate, usually via proof-of-concept. Upon
> deciding to implement OpenStack, the central documentation attempts to
> gracefully lead them toward a production deployment that meets or exceeds
> requirements and expectations.
> >
> > However, since I began contributing to OpenStack documentation around
> the Havana release, I am seeing many projects, particularly core projects,
> trending toward more independence from other projects including central
> documentation. For operator and user documentation, a couple of projects
> contribute to the central documentation repository, some projects
> contribute to their own repositories, and an alarmingly large number of
> projects simply do not contribute such documentation and assume that all
> audiences involve developers. These differences lead to an increasingly
> negative overall experience for the audiences that OpenStack needs to
> increase adoption/growth and maintain the existing deployment base.
>
> bI know the UX team have been working on getting some data around this,
> but I'd be interested to know what data you have. The User Survey
> highlighted that, while OpenStack itself is difficult to understand, most
> people are pretty happy with the current state of the documentation. Also,
> of the core projects that users interact with, we have a good relationship
> with the Cross Project Liaisons and PTLs, and are consistently working with
> them to keep docs up to date. Docs are very much a living thing, especially
> in a situation like ours, where there are a lot of components all at
> different maturity levels. Is there something specific you feel we're
> dropping a ball on?
>

Most of my data involves a combination of observations from providing
support in #openstack (and some other channels) on IRC, mailing list posts,
bug reports, and attempting to use (or reference) the existing
documentation.


>
> >
> > As a contributor to central documentation and one or more other projects
> including neutron, I see the problems from both sides and don't
> particularly blame either party for them. Some politics, some technical,
> some a lack of resources, and some just a general misunderstanding about
> documentation. However, I think we need to develop a solution that works
> for both parties and ultimately benefits our audiences.
>
> I don't think I fully understand the problem you're trying to solve here,
> yet, which makes it difficult to determine a solution.
>

I'm trying to solve the problem of the central documentation content
falling behind the development curve of OpenStack. The documentation team
can't keep up with the exponential growth of OpenStack and most projects
don't contribute sufficient documentation for the audiences that the
central documentation serves. The user guide came to mind today when I
attempted to link to it for OpenStack client commands and found out it
doesn't even mention the OSC. How do we get users to adopt the OSC if the
documentation doesn't cover it?


>
> >
> > One potential solution essentially involves moving operator and user
> documentation into project repositories (similar to developer
> documentation) and using infrastructure to coherently present it on
> docs.openstack.org  which achieves the
> following goals:
>
> But I still don't understand what problem you're solving for here. Is the
> problem that developers aren't contributing to docs? That the docs are out
> of date? That users aren't finding the right docs?
>

All of the above.


>
> >
> > 1) Project developers can contribute documentation and code in the same
> patch, thus avoiding two different review queues and reviewers with
> different motivations and guidelines.
> > 2) Project developers can either work directly or via liaison with one
> or more documentation team members to improve documentation components
> during development or after merging technically accurate content.
> > 3) Rather than attempting to document all projects with little (if any)
> assistance from those projects, the primary role of the documentation team
> becomes managing overall organization/presentation of documentation and
> assisting projects with their contributions.
> >
>
> We did something very similar with the Install Guide because it was the
> most efficient way 

Re: [openstack-dev] The future of OpenStack documentation

[Lana Brindley]

Matt,

Can you please articulate the problem you're trying to solve?

As Andreas says, we had specific problems that needed to be solved for the 
Install Guide and API docs, which is why they were done first.

Lana 

On 12/07/16 08:26, Matt Kassawara wrote:
> Andreas,
> 
> I consider the API documentation and installation guide rather complex for 
> initial content to move to project repositories and evaluate the results. 
> However, we're seeing rather strong adoption of moving API documentation 
> which I think predicts adoption of moving operator/user documentation more 
> than the installation guide. Regardless of outcome, the API documentation 
> caters to a smaller audience with at least some knowledge of OpenStack and/or 
> development experience, thus having less impact on adoption of OpenStack. On 
> the other hand, the installation guide is extremely popular and caters to a 
> larger audience with little (if any) prior knowledge of OpenStack that 
> expects the procedures to work with minimal frustration. Victimizing this 
> audience hinders adoption of OpenStack and may cast the wrong impression of 
> moving content into project repositories.
> 
> On Mon, Jul 11, 2016 at 3:52 PM, Michael Johnson  > wrote:
> 
> I support putting infrastructure in place to allow the project
> documentation to be in the project's repository.  We had problems in
> the Mitaka release with documentation getting deleted without the
> project team knowing it was happening until users were asking us where
> the documentation was located.
> 
> Having it in the repository makes it easier to review that the
> required documentation updates are being made and gives the project
> team visibility to changes in the documentation.
> 
> Michael
> 
> 
> On Sun, Jul 10, 2016 at 10:31 PM, Andreas Jaeger  > wrote:
> >
> > With Install Guide and API references, we had specific problems to
> > solve. Which ones do you see exactly with other guides?
> >
> > Also, before we discuss moving further documentation around, I'd like to
> > see first how the API references and Install guides work out and what we
> > need to improve there - before discussing next steps,
> >
> > Andreas
> > --
> >  Andreas Jaeger aj@{suse.com ,opensuse.org 
> } Twitter/Identica: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (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
> 

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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] The future of OpenStack documentation

[Matt Kassawara]

Andreas,

I consider the API documentation and installation guide rather complex for
initial content to move to project repositories and evaluate the results.
However, we're seeing rather strong adoption of moving API documentation
which I think predicts adoption of moving operator/user documentation more
than the installation guide. Regardless of outcome, the API documentation
caters to a smaller audience with at least some knowledge of OpenStack
and/or development experience, thus having less impact on adoption of
OpenStack. On the other hand, the installation guide is extremely popular
and caters to a larger audience with little (if any) prior knowledge of
OpenStack that expects the procedures to work with minimal frustration.
Victimizing this audience hinders adoption of OpenStack and may cast the
wrong impression of moving content into project repositories.

On Mon, Jul 11, 2016 at 3:52 PM, Michael Johnson 
wrote:

> I support putting infrastructure in place to allow the project
> documentation to be in the project's repository.  We had problems in
> the Mitaka release with documentation getting deleted without the
> project team knowing it was happening until users were asking us where
> the documentation was located.
>
> Having it in the repository makes it easier to review that the
> required documentation updates are being made and gives the project
> team visibility to changes in the documentation.
>
> Michael
>
>
> On Sun, Jul 10, 2016 at 10:31 PM, Andreas Jaeger  wrote:
> >
> > With Install Guide and API references, we had specific problems to
> > solve. Which ones do you see exactly with other guides?
> >
> > Also, before we discuss moving further documentation around, I'd like to
> > see first how the API references and Install guides work out and what we
> > need to improve there - before discussing next steps,
> >
> > Andreas
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] why do we need setting network driver per node?

[Sam Betts (sambetts)]

Thanks for following up with this Devananda, I¹ve left a couple of
corrections to my proposal inline, unfortunately IRC isn¹t the best for
putting ideas this complex across :)

Sam

On 11/07/2016 21:57, "Devananda van der Veen" 
wrote:

>We spent the majority of today's weekly IRC meeting [1] discussing the
>finer
>points of this question. I agreed to post a summary of those to the list
>(it's
>below the break).
>
>tldr;
>
>* we don't know if network_interface should behave like other hardware
>interfaces, but...
>* we need to come to an agreement on it this week, so we can proceed with
>the
>network integration work.
>
>
>Background:
>
>- As proposed in the driver composition reform spec [2], each
>hardware_type
>class (eg, ilo_gen8) shall specify a set of allowable interface
>implementations
>(eg, noop, flat, neutron are all network_interfaces) for each interface
>type
>(eg, deploy_interface, power_interface, network_interface).
>- A hardware_type shall also indicate a default for each interface_type.
>(**
>this is what we debated ** )
>- There is no CONF option to specify a global default for each
>interface_type
>(eg, there is no CONF.default_power_interface setting, because it varies
>by
>hardware_type)
>- There will be a CONF option to enable ("allow") hardware classes and
>CONF
>options to enable ("allow") interface classes.
>
>
>Points raised in the meeting today:
>
>- in "most" cases, network_interface will depend more on the environment
>than a
>specific Node's hardware or out-of-band management device
>
>- in "exceptional" cases, a Node may only support specific
>network_interfaces
>(eg, certain Cisco hardware, a Blade enclosure)
>
>- maybe hardware_type should specify a default for some interfaces but not
>others? Example:
>  - the ilo_gen8 hardware class should specify power, deploy, and
>management
>interface defaults to ilo-specific interface classes
>  - but the operator should set the network interface as appropriate to
>their
>environment
>
>- if we were to force the operator to specify Node.network_interface (but
>not
>any other interface) when enrolling every node, this will be apoor
>experience.
>
>- we should add a global CONF setting to allow operators to set a default
>network interface for their environment.
>
>- words are hard. we shouldn't call network_interface an "interface" if it
>behaves differently than other interfaces.
>
>- we have two "types" of interfaces on drivers: hardware-types and
>environment-types. maybe we should treat them differently?
>
>- other things also depend on the environment (rather than the Node's
>hardware
>or BMC) such as deploy_interface and volume_interface.
>
>
>There was a proposal from sambetts towards the end of the meeting, which
>I've
>edited for clarity (please correct if I misunderstood any of your
>points). This
>seems to capture/address most of the points above and proposes a way
>forward,
>while keeping within the intent of our driver composition reform spec. It
>was
>the only clear suggestion during the meeting.
>
>- in-tree hardware_types declare supported_network_interfaces to be empty
>[4]
>and declare no default_network_interface

Your suggestion in [4] is what I meant, but I couldn¹t type fast enough in
the meeting. In-tree hardware_types will list support for
network_interfaces according to their vendor¹s preference (I expect for
most/all drivers that will at least be [noop, flat, neutron]). And if in
the future as a vendor I want to, for example, push my hardware specific
network interface in tree, then my Cisco drivers will gain an additional
network_interface in their supported_network_interfaces list, [noop, flat,
neutron, cisco].

>- we add a CONF option for default_network_interface, with a sane default
>value
>- this CONF option is validated on conductor load to be supported by all
>loaded
>hardware_types, and the conductor refuses to start if this CONF option is
>set to
>a value not supported by one or more enabled_hardware_types
>- if a(n out of tree) hardware_type declares a default_network_interface,
>this
>will take precedence over the CONF option

I believe that all hardware_types should specify their supported network
interfaces, but none should specify a default network interface, because
there is no way to define a sane default in the hardware_type without
knowing what environment its being deployed into.

>- a node created without specifying a network interface will check the
>hardware_type's supported_network_interfaces, and when that is empty,
>fall back
>to the CONF.default_network_interface, just as other interfaces fall back
>to the
>hardware_type's relevant default

A node created without specifying a specific network interface will get
the default specified by the CONF option, which we know is supported by
that hardware_type because of the validation on conductor start. Nodes
created with a network_interface specified work with the usual rules as
you've specified below.

>- 

[openstack-dev] [neutron] N2 deliverables contents

[Ihar Hrachyshka]

Hi neutrinos,

We’ll need to produce N2 milestone deliverables this week (neutron + 
neutron-*aas). Do we have any patches in flight that could benefit from being 
landed now and not in N3? If so, please raise a flag in this thread, and we 
will consider candidates case by case.

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

Re: [openstack-dev] The future of OpenStack documentation

[Michael Johnson]

I support putting infrastructure in place to allow the project
documentation to be in the project's repository.  We had problems in
the Mitaka release with documentation getting deleted without the
project team knowing it was happening until users were asking us where
the documentation was located.

Having it in the repository makes it easier to review that the
required documentation updates are being made and gives the project
team visibility to changes in the documentation.

Michael


On Sun, Jul 10, 2016 at 10:31 PM, Andreas Jaeger  wrote:
>
> With Install Guide and API references, we had specific problems to
> solve. Which ones do you see exactly with other guides?
>
> Also, before we discuss moving further documentation around, I'd like to
> see first how the API references and Install guides work out and what we
> need to improve there - before discussing next steps,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[Joshua Harlow]

Woot, we in oslo talked about it during today's meeting and from what I 
can tell we'd like to have the moose that we currently have adjusted as 
needed and continue forward with that (we've been using this logo for a 
while already in stickers...):


https://wiki.openstack.org/wiki/File:Oslo-moose-color.svg

But unification and making it more professional and all that would be 
much appreciated :)


-Josh

Heidi Joy Tretheway wrote:

The Foundation would like to help promote OpenStack projects in the big
tent with branding and marketing services. The idea is to create a
family of logos for OpenStack projects that are unique, yet immediately
identifiable as part of OpenStack. We’ll be using these logos to promote
your project on the OpenStack website, at the Summit and in marketing
materials.

We’re asking project teams to choose a mascot to represent as their
logo. Your team can select your own mascot, and then we’ll have an
illustrator create the logo for you (and we also plan to print some
special collateral for your team in Barcelona).

If your team already has a logo based on a mascot from nature, you’ll
have first priority to keep that mascot, and the illustrator will
restyle it to be consistent with the other projects. If you have a logo
that doesn’t have a mascot from nature, we encourage your team to choose
a mascot.

Here’s an FAQ and examples of what the logos can look like:
http://www.openstack.org/project-mascots
We’ve also recorded a quick video with an overview of the project:
https://youtu.be/LOdsuNr2T-o

You can get in touch with your PTL to participate in the logo choice
discussion. If you have more questions, I’m happy to help. :-)

Cheers,
Heidi Joy

__
Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | skype: heidi.tretheway





__
OpenStack Development Mailing List (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 and MTU advertisements -- post newton

[Ian Wells]

On 11 July 2016 at 12:52, Sam Yaple  wrote:

> After lots of fun on IRC I have given up this battle. I am giving up
> quickly because frickler has purposed a workaround (or better solution
> depending on who you ask). So for all of you keeping track at home, if you
> want your vxlan and your vlan networks to have the same MTU, here are the
> relevant options to set as of Mitaka.
>

> [DEFAULT]
> global_physnet_mtu = 1550
> [ml2]
> path_mtu = 1550
> physical_network_mtus = physnet1:1500
>
> This should go without saying, but i'll say it anyway: Your underlying
> network interface must be at least 1550 MTU for the above config to result
> in all instances receiving 1500 mtu regardless of network type. If you want
> some extra IRC reading, there was a more extensive conversation about this
> [1]. Good luck, you'll need it.
>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-07-11.log.html#t2016-07-11T13:39:45
>

To be fair, what was said on there doesn't apply to this fix (which I
hadn't seen - I think it was in the channel before I joined).

You were suggesting that you should still be able to disable MTU
advertisement - which, as I pointed out, wouldn't do what you wanted, as it
would leave the ports used for DHCP, routing and metatdata servers all with
different IPs to your instances in some cases, and likely this would break
your system in exciting and unpredictable ways.

The fix proposed does *not* disable MTU advertisement, however.  It will
make Neutron calculate a 1500 MTU for VLAN and VXLAN networks, both - which
it will advertise, but that's effectively a no-op and I imagine you don't
really care.  The more important thing, though, is that Neutron now
understands that the MTUs are 1500 and it will apply that properly to its
service ports.  The solution above makes good sense and is much better than
disabling advertisement - go with it.
-- 
Ian.
__
OpenStack Development Mailing List (not for 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] why do we need setting network driver per node?

[Devananda van der Veen]

We spent the majority of today's weekly IRC meeting [1] discussing the finer
points of this question. I agreed to post a summary of those to the list (it's
below the break).

tldr;

* we don't know if network_interface should behave like other hardware
interfaces, but...
* we need to come to an agreement on it this week, so we can proceed with the
network integration work.


Background:

- As proposed in the driver composition reform spec [2], each hardware_type
class (eg, ilo_gen8) shall specify a set of allowable interface implementations
(eg, noop, flat, neutron are all network_interfaces) for each interface type
(eg, deploy_interface, power_interface, network_interface).
- A hardware_type shall also indicate a default for each interface_type. (**
this is what we debated ** )
- There is no CONF option to specify a global default for each interface_type
(eg, there is no CONF.default_power_interface setting, because it varies by
hardware_type)
- There will be a CONF option to enable ("allow") hardware classes and CONF
options to enable ("allow") interface classes.


Points raised in the meeting today:

- in "most" cases, network_interface will depend more on the environment than a
specific Node's hardware or out-of-band management device

- in "exceptional" cases, a Node may only support specific network_interfaces
(eg, certain Cisco hardware, a Blade enclosure)

- maybe hardware_type should specify a default for some interfaces but not
others? Example:
  - the ilo_gen8 hardware class should specify power, deploy, and management
interface defaults to ilo-specific interface classes
  - but the operator should set the network interface as appropriate to their
environment

- if we were to force the operator to specify Node.network_interface (but not
any other interface) when enrolling every node, this will be apoor experience.

- we should add a global CONF setting to allow operators to set a default
network interface for their environment.

- words are hard. we shouldn't call network_interface an "interface" if it
behaves differently than other interfaces.

- we have two "types" of interfaces on drivers: hardware-types and
environment-types. maybe we should treat them differently?

- other things also depend on the environment (rather than the Node's hardware
or BMC) such as deploy_interface and volume_interface.


There was a proposal from sambetts towards the end of the meeting, which I've
edited for clarity (please correct if I misunderstood any of your points). This
seems to capture/address most of the points above and proposes a way forward,
while keeping within the intent of our driver composition reform spec. It was
the only clear suggestion during the meeting.

- in-tree hardware_types declare supported_network_interfaces to be empty [4]
and declare no default_network_interface
- we add a CONF option for default_network_interface, with a sane default value
- this CONF option is validated on conductor load to be supported by all loaded
hardware_types, and the conductor refuses to start if this CONF option is set to
a value not supported by one or more enabled_hardware_types
- if a(n out of tree) hardware_type declares a default_network_interface, this
will take precedence over the CONF option
- a node created without specifying a network interface will check the
hardware_type's supported_network_interfaces, and when that is empty, fall back
to the CONF.default_network_interface, just as other interfaces fall back to the
hardware_type's relevant default
- operators can override a specific node's network_interface, which follows the
usual rules for setting an interface on a Node (ie, the interface must be in
hardware_type.supported_network_interfaces AND in 
CONF.enabled_network_interfaces)


If anyone else has other clear suggestions that address all the issues here,
please reply with them.

I'm going to make myself available tomorrow at 1700 UTC, in both IRC and by
voice [3] (conference line # TBD) to discuss this with anyone. If we need to
discuss it again on Wednesday, we can.


Thanks much,
--devananda



[1] starting at 17:20

http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-07-11-17.00.log.html

[2]
http://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-composition-reform.html

[3] https://wiki.openstack.org/wiki/Infrastructure/Conferencing

[4] I think we may need to have in-tree drivers declare
supported_network_interfaces to be [noop, flat, neutron], but that is not what
Sam suggested during the meeting



On 06/28/2016 08:32 AM, Dmitry Tantsur wrote:
> Hi folks!
> 
> I was reviewing https://review.openstack.org/317391 and realized I don't quite
> understand why we want to have node.network_interface. What's the real life 
> use
> case for it?
> 
> Do we expect some nodes to use Neutron, some - not?
> 
> Do we expect some nodes to benefit from network separation, some - not? There
> may be a use case here, but then we have to expose this field to Nova for
> 

Re: [openstack-dev] [TripleO][docs]: Undercloud install fails with unavailability of oslo::cache

[Ben Nemec]

On 07/08/2016 12:27 PM, Paddu Krishnan (padkrish) wrote:
> Thanks a lot for the reply. Pls see inline..
> 
> On 7/8/16, 7:47 AM, "Ben Nemec"  wrote:
> 
>> On 07/08/2016 12:58 AM, Paddu Krishnan (padkrish) wrote:
 Hello,
 I am trying to install TripleO in a VM environment. It¹s a basic
 install.
 I am following the instructions in
  
 http://docs.openstack.org/developer/tripleo-docs/installation/installati
 on.html. I
 am following the instructions for the stable branch.

 Installing the undercloud (³openstack undercloud install²) failed with
 the below logs. Inspite of me giving the repo as
 liberty,  
 /usr/share/tripleo-image-elements/rdo-release/environment.d/10-rdo-relea
 se-name.bash
 was set to kilo. I modified it to liberty.

 I also made changes in
  /usr/lib/python2.7/site-packages/tripleoclient/v1/overcloud_image.py
 to point to liberty as mentioned
 in https://bugzilla.redhat.com/show_bug.cgi?id=1304395.
>>
>> You should not make any code changes to install Liberty.  I just tried
>> it and it worked fine with the current code.
> 
> #padkrish# I did not do this earlier. Then I found
> /usr/share/tripleo-image-elements/rdo-release/environment.d/10-rdo-release-
> name.bash and  
> /usr/lib/python2.7/site-packages/tripleoclient/v1/overcloud_image.py in
> the undercloud VM had Kilo instead of liberty. I am going to try few more
> suggestions. If it doesn¹t work, I will start from scratch in building the
> undercloud VM and share the logs.
>  
>>

 I did not get any errors in the previous commands. From the error, I
 can only guess all the puppet modules (oslo::cache?) were not
 completely installed. Any tips on overcoming this would be great.

 ‹‹-
 dib-run-parts Tue Jul  5 16:15:01 EDT 2016 Running
 /usr/libexec/os-refresh-config/configure.d/50-puppet-stack-config
 + set -o pipefail
 + set +e
 + puppet apply --detailed-exitcodes
 /etc/puppet/manifests/puppet-stack-config.pp
 Error: Resource type oslo::cache doesn't exist on node
 instack.localdomain
 Error: Resource type oslo::cache doesn't exist on node
 instack.localdomain
 + rc=1
 + set -e
 + echo 'puppet apply exited with exit code 1'
 puppet apply exited with exit code 1
 + '[' 1 '!=' 2 -a 1 '!=' 0 ']'
 + exit 1
 [2016-07-05 16:15:06,463] (os-refresh-config) [ERROR] during configure
 phase. [Command '['dib-run-parts',
 '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit
 status 1]

 [2016-07-05 16:15:06,463] (os-refresh-config) [ERROR] Aborting...
 Traceback (most recent call last):
   File "", line 1, in 
   File
 "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
 line 815, in install
 _run_orc(instack_env)
   File
 "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
 line 699, in _run_orc
 _run_live_command(args, instack_env, 'os-refresh-config')
   File
 "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
 line 370, in _run_live_command
 raise RuntimeError('%s failed. See log for details.' % name)
 RuntimeError: os-refresh-config failed. See log for details.
 Command 'instack-install-undercloud' returned non-zero exit status 1

 

 I also manually tried to install the oslo packages, that didn¹t help
 either.

 As suggested by shardy, I also tried the ³tripleo.sh  ‹repo-setup².
 Still the same error.
>>
>> What is the output of `cat /etc/yum.repos.d/delorean*` ?  You may have
>> conflicting repos if you used both the doc repo setup and the tripleo.sh
>> one.  Deleting /etc/yum.repos.d/delorean* and re-running tripleo.sh
>> --repo-setup may help (don't forget to export STABLE_RELEASE=liberty
>> first).
> 
> #padkrish# Just tried your suggestion and unfortunately that didn¹t help
> either :(. Here it is:
>  

Okay, it looks like you're running on RHEL?  I wouldn't suggest that
with the upstream bits.  We don't test on RHEL upstream and there's
actually discussion going on right now about removing the RHEL docs
since there are reports that it doesn't work right anyway.

I don't know for sure if that's the problem here, but using CentOS would
be your best bet to get it working.

> 
> 
> Thanks again,
> Paddu
> 
> 
>>
>> For the moment I would ignore the documentation on repo setup and image
>> building and use tripleo.sh for those parts.  Both those sections are
>> different from what we CI and I believe both are probably broken right
>> now.  I'm trying to fix this divergence, but progress is slow so far. :-(
>>

>>> From yum list:
>>>
>>> ‹‹‹-
>>> python-oslo-cache.noarch 0.7.0-1.el7
>>> delorean-liberty-testing
>>> python-oslo-cache-doc.noarch
>>> 

Re: [openstack-dev] Neutron and MTU advertisements -- post newton

[Ihar Hrachyshka]

> On 11 Jul 2016, at 15:52, Sam Yaple  wrote:
> 
> After lots of fun on IRC I have given up this battle. I am giving up quickly 
> because frickler has purposed a workaround (or better solution depending on 
> who you ask). So for all of you keeping track at home, if you want your vxlan 
> and your vlan networks to have the same MTU, here are the relevant options to 
> set as of Mitaka.
> 
> [DEFAULT]
> global_physnet_mtu = 1550
> [ml2]
> path_mtu = 1550
> physical_network_mtus = physnet1:1500

I believe your request is corner case, and as long as we have a way to solve 
the issue for you, we should be ok.

Note that if you use IPv6 endpoints, you need to use a higher value for 
path_mtu:

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

> 
> This should go without saying, but i'll say it anyway: Your underlying 
> network interface must be at least 1550 MTU for the above config to result in 
> all instances receiving 1500 mtu regardless of network type. If you want some 
> extra IRC reading, there was a more extensive conversation about this [1]. 
> Good luck, you'll need it.
> 
> [1] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-07-11.log.html#t2016-07-11T13:39:45
> 
> Sam Yaple
> 
> On Mon, Jul 11, 2016 at 7:22 PM, Fox, Kevin M  wrote:
> I fought for two weeks to figure out why one of my clouds didn't seem to want 
> to work properly. It was in fact one of those helpful souls you mention below 
> filtering out PMTU's. I had to play with some rather gnarly iptables rules to 
> workaround the issue. -j TCPMSS --clamp-mss-to-pmtu
> 
> So it does happen.
> 
> Thanks,
> Kevin
> 
> From: Ian Wells [ijw.ubu...@cack.org.uk]
> Sent: Monday, July 11, 2016 12:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Neutron and MTU advertisements -- post newton
> 
> On 11 July 2016 at 11:49, Sean M. Collins  wrote:
> Sam Yaple wrote:
> > In this situation, since you are mapping real-ips and the real world runs
> > on 1500 mtu
> 
> Don't be so certain about that assumption. The Internet is a very big
> and diverse place
> 
> OK, I'll contradict myself now - the original question wasn't L2 transit.  
> Never mind.
> 
> That 'inter' bit is actually rather important.  MTU applies to a layer 2 
> domain, and routing is designed such that the MTUs on the two ports of a 
> router are irrelevant to each other.  What the world does has no bearing on 
> the MTU I want on my L2 domain, and so Sam's point - 'I must choose the MTU 
> other people use' - is simply invalid.  You might reasonably want your 
> Neutron router to have an external MTU of 1500, though, to do what he asks in 
> the face of some thoughtful soul filtering out PMTU exceeded messages.  I 
> still think it comes back to the same thing as I suggested in my other mail.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [tripleo] remaining work on composable roles

[Emilien Macchi]

Hi,

Since the etherpad [1] started to be too big, we started to use
Launchpad to track what needs to be done.
In the list:
- MySQL Galera (WIP)
- Pacemaker service (WIP)
- Telemetry (Ceilometer, Aodh, Gnocchi) (WIP) - really good progress
- Last bits on Nova / Neutron - Almost done
- Swift Ringbuilder (WIP)

If you're working on this topic, please file a bug in Launchpad and
target it to newton-3 and add the "composable-roles" tag:
https://bugs.launchpad.net/tripleo/+bugs?field.tag=composable-roles

It will help to track the work that needs to be finished before Neutron release.

Thanks,

[1] https://etherpad.openstack.org/p/tripleo-composable-services <---
really to big :)
-- 
Emilien Macchi

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

Re: [openstack-dev] Neutron and MTU advertisements -- post newton

[Sam Yaple]

After lots of fun on IRC I have given up this battle. I am giving up
quickly because frickler has purposed a workaround (or better solution
depending on who you ask). So for all of you keeping track at home, if you
want your vxlan and your vlan networks to have the same MTU, here are the
relevant options to set as of Mitaka.

[DEFAULT]
global_physnet_mtu = 1550
[ml2]
path_mtu = 1550
physical_network_mtus = physnet1:1500

This should go without saying, but i'll say it anyway: Your underlying
network interface must be at least 1550 MTU for the above config to result
in all instances receiving 1500 mtu regardless of network type. If you want
some extra IRC reading, there was a more extensive conversation about this
[1]. Good luck, you'll need it.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-07-11.log.html#t2016-07-11T13:39:45

Sam Yaple

On Mon, Jul 11, 2016 at 7:22 PM, Fox, Kevin M  wrote:

> I fought for two weeks to figure out why one of my clouds didn't seem to
> want to work properly. It was in fact one of those helpful souls you
> mention below filtering out PMTU's. I had to play with some rather gnarly
> iptables rules to workaround the issue. -j TCPMSS --clamp-mss-to-pmtu
>
> So it does happen.
>
> Thanks,
> Kevin
>
> --
> *From:* Ian Wells [ijw.ubu...@cack.org.uk]
> *Sent:* Monday, July 11, 2016 12:04 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] Neutron and MTU advertisements -- post
> newton
>
> On 11 July 2016 at 11:49, Sean M. Collins  wrote:
>
>> Sam Yaple wrote:
>> > In this situation, since you are mapping real-ips and the real world
>> runs
>> > on 1500 mtu
>>
>> Don't be so certain about that assumption. The Internet is a very big
>> and diverse place
>
>
> OK, I'll contradict myself now - the original question wasn't L2 transit.
> Never mind.
>
> That 'inter' bit is actually rather important.  MTU applies to a layer 2
> domain, and routing is designed such that the MTUs on the two ports of a
> router are irrelevant to each other.  What the world does has no bearing on
> the MTU I want on my L2 domain, and so Sam's point - 'I must choose the MTU
> other people use' - is simply invalid.  You might reasonably want your
> Neutron router to have an external MTU of 1500, though, to do what he asks
> in the face of some thoughtful soul filtering out PMTU exceeded messages.
> I still think it comes back to the same thing as I suggested in my other
> mail.
>
> __
> OpenStack Development Mailing List (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] weekly subteam status report

[Loo, Ruby]

Hi,

We are veracious to present this week's subteam report for Ironic. As usual, 
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 27 June 2016)
- Ironic: 197 bugs (-10) + 197 wishlist items (+6). 10 new (-2), 142 in 
progress (+2), 0 critical, 29 high (-3) and 25 incomplete (-1)
- Inspector: 9 bugs (+2) + 21 wishlist items (+1). 0 new, 7 in progress (+2), 0 
critical, 2 high (+1) and 2 incomplete (+1)
- Nova bugs with Ironic tag: 11 (-3). 1 new (+1), 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll, TheJulia, devananda)

* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- Currently blocked on contention regarding network_interface, and a possible 
default value which conflicts with the driver composition model.
- The nova FF has passed and https://review.openstack.org/#/c/297895/ is 
dependent upon the ironic code landing.

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
- the last inspector gate job (source job running on IPA) is switched to tinyipa

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- Spec still in review.

Agent top-level API promotion (dtantsur)

* trello: 
https://trello.com/c/37YuKIB8/28-promote-agent-vendor-passthru-to-core-api
- code patches are up and under review: 
https://review.openstack.org/#/q/topic:bug/1570841

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- started working on code patches

OpenStackClient plugin for ironic (thrash, dtantsur, rloo)
==
* trello: https://trello.com/c/ckqtq3kG/16-openstackclient-plugin-for-ironic
- stalled, needs someone to check the spec against the actual code
- rloo volunteers to do this fun job

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- code patches are up and need reviews. just rebased after merge conflict from 
friday, so jenkins is reverifying
- https://review.openstack.org/#/c/298461/ had a +2 and a +1 before, 
responded to -1 comments after that
- https://review.openstack.org/#/c/321865/

Keystone policy support (JayF, devananda)
=
* trello: https://trello.com/c/P5q3Es2z/15-keystone-policy-support
- Spec needs reviews
- Code is in progress, needs some more work

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- Ironic:
- spec: approved
- code: needs review
- Nova:
- spec: not required
- code: needs review
Nova Feature Freeze was last week and this didn't get a FFE (feature freeze 
exception) so will not land in Newton

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- stalled on getting nova's ops matcher into oslo.utils for use by ironic

Rescue mode (JayF)
==
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- spec needs reviews still

Inspector (dtansur)
===
- Our grenade job passed for the first time and now runs non-voting in the 
check pipeline
- It does not run any inspection tests though, working on it: 
https://review.openstack.org/336532
- blocked by grenade patch: https://review.openstack.org/337372
- newton-2 releases were done

Cross-project:
==
- QA (dtantsur)
- the gate is moving from Python 3.4 to Python 3.5. There will be a new 
non-voting job very soon. It's up to us when we decide to switch our master to 
Python 3.5. Stable branches stay on 3.4. Details: 
http://lists.openstack.org/pipermail/openstack-dev/2016-July/098665.html

Drivers:

iLO (wanyen)
 - The CI is enabled for all three ilo drivers. Due to some space issue on the 
base hardware where we have jenkins setup, we have temporarily shut down the CI.
- The patches https://review.openstack.org/264590 and 
https://review.openstack.org/266803 are there in review from long time and 
needed for ilo drivers CI. Since these are not getting reviews, they move to 
merge conflict state any time.

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard

__
OpenStack Development Mailing List (not for 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 and MTU advertisements -- post newton

[Fox, Kevin M]

I fought for two weeks to figure out why one of my clouds didn't seem to want 
to work properly. It was in fact one of those helpful souls you mention below 
filtering out PMTU's. I had to play with some rather gnarly iptables rules to 
workaround the issue. -j TCPMSS --clamp-mss-to-pmtu

So it does happen.

Thanks,
Kevin


From: Ian Wells [ijw.ubu...@cack.org.uk]
Sent: Monday, July 11, 2016 12:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Neutron and MTU advertisements -- post newton

On 11 July 2016 at 11:49, Sean M. Collins 
> wrote:
Sam Yaple wrote:
> In this situation, since you are mapping real-ips and the real world runs
> on 1500 mtu

Don't be so certain about that assumption. The Internet is a very big
and diverse place

OK, I'll contradict myself now - the original question wasn't L2 transit.  
Never mind.

That 'inter' bit is actually rather important.  MTU applies to a layer 2 
domain, and routing is designed such that the MTUs on the two ports of a router 
are irrelevant to each other.  What the world does has no bearing on the MTU I 
want on my L2 domain, and so Sam's point - 'I must choose the MTU other people 
use' - is simply invalid.  You might reasonably want your Neutron router to 
have an external MTU of 1500, though, to do what he asks in the face of some 
thoughtful soul filtering out PMTU exceeded messages.  I still think it comes 
back to the same thing as I suggested in my other mail.
__
OpenStack Development Mailing List (not for 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 and MTU advertisements -- post newton

[Ian Wells]

On 11 July 2016 at 11:49, Sean M. Collins  wrote:

> Sam Yaple wrote:
> > In this situation, since you are mapping real-ips and the real world runs
> > on 1500 mtu
>
> Don't be so certain about that assumption. The Internet is a very big
> and diverse place


OK, I'll contradict myself now - the original question wasn't L2 transit.
Never mind.

That 'inter' bit is actually rather important.  MTU applies to a layer 2
domain, and routing is designed such that the MTUs on the two ports of a
router are irrelevant to each other.  What the world does has no bearing on
the MTU I want on my L2 domain, and so Sam's point - 'I must choose the MTU
other people use' - is simply invalid.  You might reasonably want your
Neutron router to have an external MTU of 1500, though, to do what he asks
in the face of some thoughtful soul filtering out PMTU exceeded messages.
I still think it comes back to the same thing as I suggested in my other
mail.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [constraints] Updating stable branch URL

[Doug Hellmann]

Excerpts from Sachi King's message of 2016-06-30 14:24:45 +1000:
> On Tue, Jun 28, 2016 at 9:38 AM, Tony Breeds  wrote:
> > On Mon, Jun 27, 2016 at 11:28:47PM +, Jeremy Stanley wrote:
> >
> >> I want to say there was a reason we were branching the requirements
> >> repo last, but now I can't remember what it is (or if we even did
> >> branch it last). Thierry or Doug likely recall but are indisposed
> >> this week so I suggest waiting until they're around to reply before
> >> making a decision on this anyway (especially since it's the Release
> >> Managers who will need to adjust that process if it does merit
> >> changing).
> 
> I don't remember the specifics, but I had a chat about this some time
> ago, and concur.  As well, requirements branched a couple weeks after
> both Nova and Neutron this time around, I didn't check any others.

Looking back at my mitaka notes, it appears we scheduled the branch
for the requirements repo for the RC1 week, but then put it off
because we wanted to wait until all of the branches for the managed
projects had been created, so we took care of it the following week.
That matches the ~1 week difference between the .gitreview update for
openstack/nova and openstack/requirements.

> Regardless, I don't think there is any way to make a compelling
> argument that the constraints URL should ever dictate when
> the reqs repo should be branched, even if there weren't current
> restrictions to this.
> 
> > I'm not certain how this is different to updating .gitreview and the default
> > branch?  Can't we extend the tools[1] that do that step with the updating of
> > tox.ini?
> 
> I initially had the same thought as Jeremy here, forgetting it could sit in
> review on the stable branch.  While having it sit in the queue and needing
> to be manually checked if it can be merged yet is sub-optimal, I think that
> is probably the best option so far.  The commit message could contain
> details as to the limitations/a link to documentation.

Yes, I think updating that branching script is the best course.

We might want to modify the tox.ini to make it easier to edit with
sed by defining a variable for the branch. It would be nice if we
could just read the value from the .gitreview file, but that might
be trickier than we want to be. The script that creates the branches
is:
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/make_stable_branch.sh

> 
> > It could be worked around with
> > additional logic to fall back on the master URL if the branch
> > doesn't exist, but it's also possible we just document this as a
> > shortcoming for the sake of simplicity.
> 
> This would be wonderful, but I think it would raise the barrier
> to entry on constraints a bit too high and would end up relying
> a bit too much on un-gated code that would mostly be cargo-cult.
> To support this with tox, would require wrapping the tox
> install_command on any project that wishes to use constraints,
> and modifying existing wrapped install_command, which is
> common with the neutron-*aas projects, without any easy way
> to update any of them.
> 
> > OK, lets wait and see what they say.
> 
> Sounds good.
> 
> Cheers,
> Sachi
> 

__
OpenStack Development Mailing List (not for 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 and MTU advertisements -- post newton

[Ian Wells]

On 11 July 2016 at 11:12, Chris Friesen  wrote:

> On 07/11/2016 10:39 AM, Jay Pipes wrote:
>
> Out of curiosity, in what scenarios is it better to limit the instance's
>> MTU to
>> a value lower than that of the maximum path MTU of the infrastructure? In
>> other
>> words, if the infrastructure supports jumbo frames, why artificially
>> limit an
>> instance's MTU to 1500 if that instance could theoretically communicate
>> with
>> other instances in the same infrastructure via a higher MTU?
>>
>
> It is my understanding that using the max path MTU is ideal, but that not
> all software does path MTU discovery.  Also, some badly-designed security
> devices can mess up PMTUD.


Ignoring PMTUD cases, which are routed (the original question was L2
transit), there are several use cases for specific networks having MTUs
other than 9000.  Maybe you're talking to a device on a provider network
that has a 1500 MTU not under your control, for instance.  It's also
reasonable to have a cloud with a high internal MTU and a low external
network MTU - maybe you have control over your own domain but not the whole
network in which you're situated.

That is *not*, in fact, the same as having no MTU advertisement (but it
seems to address the use case originally mentioned; if you could be
selective about the MTU you used and the advertisements were corrected
accordingly you could simply choose 1500).  There are also ports that need
an MTU - router ports, DHCP ports - that are not receiving it via MTU
advertisement, so  turning advertisement off and letting nature take its
course doesn't work for everything.

The original MTU spec [1] - which never got fully implemented - detailed
the intent, which was that OpenStack would choose a sensible default MTU
value and advertise it, and that you could override that value for your own
purposes.  I still think we need to implement the missing bits.
-- 
Ian.

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html
- the bit that wasn't completed was 'the tenant can request a specific MTU
on a network' - which, incidentally, is not 'the network will not pass
packets bigger than X', but simply 'OpenStack and the tenant will agree
that X is the MTU that ports shall use on that network; packets that size
or less are guaranteed to pass over the L2 domain unmolested, and where an
MTU is set on a port or advertised to it that will be the one'.  If you
want a lecture on cloud MTUs I can give one.  But you really, really don't.
__
OpenStack Development Mailing List (not for 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 and MTU advertisements -- post newton

[Sean M. Collins]

Sam Yaple wrote:
> In this situation, since you are mapping real-ips and the real world runs
> on 1500 mtu

Don't be so certain about that assumption. The Internet is a very big
and diverse place

-- 
Sean M. Collins

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

[openstack-dev] [Fuel] New version of fuel-devops (2.9.21)

[Dennis Dmitriev]

Hi All,

We are going to update the 'fuel-devops' framework on our product CI to
the version 2.9.21.

Changes since 2.9.20:

* For devops:

  - Scripts for export and import systest environments, based on
external libvirt snapshots [1]
  - Disable creation of nwfilters by default [2]
  - Get rid from log.yaml file, logger and it's settings were moved into
scripts [3]
  - Do not use database ids in bridge and interface names, that allows
to use several different virtual environments with different set of
requirements on the same host [4] [5] [6]

* For QA automation:

  - 'ipaddr' was replaced with 'netaddr'  [7]
  - Use keystoneauth1 package for authorization to Nailgun [8]
  - Move the method execute_through_host() from fuel-qa to SSHClient [9]
  - Methods that allow to change boot order and close tray for Node [10]
  - Lots of SSHClient improvements [11] [12] [13] [14] [15]
  - Improvements for compatibility with python3

List of all changes can be found on github [16].

[1] https://review.openstack.org/#/c/280573/
[2] https://review.openstack.org/#/c/313082/
[3] https://review.openstack.org/#/c/320366/
[4] https://review.openstack.org/#/c/327082/
[5] https://review.openstack.org/#/c/336057/
[6] https://review.openstack.org/#/c/339811/
[7] https://review.openstack.org/#/c/299428/
[8] https://review.openstack.org/#/c/314505/
[9] https://review.openstack.org/#/c/319920/
[10] https://review.openstack.org/#/c/331660/
[11] https://review.openstack.org/#/c/331120/
[12] https://review.openstack.org/#/c/327656/
[13] https://review.openstack.org/#/c/327180/
[14] https://review.openstack.org/#/c/326462/
[15] https://review.openstack.org/#/c/338161/
[16] - https://github.com/openstack/fuel-devops/compare/2.9.20...release/2.9

-- 
Regards,
Dennis Dmitriev
QA Engineer,
Mirantis Inc. http://www.mirantis.com
e-mail/jabber: ddmitr...@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

[openstack-dev] [Infra] Meeting Tuesday July 12th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday July 12th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-05-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-05-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-07-05-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing List (not for 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 and MTU advertisements -- post newton

[Matt Kassawara]

All MTU changes must occur on a layer-3 device, typically a router. If a
router receives a packet with an MTU larger than the next-hop interface, it
can either fragment it or use path MTU discovery (PMTUD) to inform the
sender of the next-hop interface MTU value [1]. Fragmentation causes
performance problems and all modern layer-3 devices support PMTUD. Thus,
unless explicitly disabled (or broken by blocking ICMP), PMTUD provides an
optimal solution that enables the sender to retransmit the initial packet
and any future packets without fragmentation.

[1] https://en.wikipedia.org/wiki/IP_fragmentation

On Mon, Jul 11, 2016 at 11:18 AM, Sam Yaple  wrote:

> On Mon, Jul 11, 2016 at 4:39 PM, Jay Pipes  wrote:
>
>> On 07/11/2016 07:45 AM, Sam  Yaple wrote:
>>
>>> Hello,
>>>
>>> There was alot of work to get MTU advertisement working well in Mitaka.
>>> With the work that was done we can finally have 1500 mtu networks for
>>> tunneled networks if the underlying infrastructure supports jumbo frames.
>>>
>>> Its fantastic for people who have 1500 mtu networks and want to use
>>> vxlan, no more hacks to get the instance to use 1450 mtu. Its fantastic
>>> for people who want to use 1500+ networks and get the instances setup
>>> with 9000 mtu interfaces. Its is not good for people who want consistent
>>> mtu no matter the network type. But thats fine, since mtu advertisement
>>> _could_ be disabled. Its a fantastic default to have it turned on.
>>>
>>> With a recent patchset [1] the ability to turn off MTU advertisements
>>> was deprecated in Newton. In the review it was stated there is no valid
>>> use case for it. I disagree.
>>>
>>> The scenario is the infrastructure has jumbo frames enabled, but I do
>>> not want the instances to be using jumbo frames, but I want them to be
>>> using the default 1500 mtu that the rest of the world operates on. This
>>> would still setup all of the virtual switching infrastructure to the
>>> correct MTUs, but not try to adjust the instances MTUs. In this way the
>>> instances are only communicating at 1500 mtu, but never having to
>>> fragment/drop inside of the SDN when communicating with other networks
>>> even if it is a VXLAN or other tunneled network.
>>>
>>> Without the option to disable mtu advertisement, inside the same
>>> environment flat/vlan and gre/vxlan network will always have different
>>> mtu, even if the backend supports jumbo frames.
>>>
>>> My ask is we keep the advertise_mtu option, and keep it enabled by
>>> default. This would allow for the default, common 1500 mtu across
>>> networks of different types.
>>>
>>> This scenario would be very similiar to having a computer with 1500 mtu
>>> attached to a switch which supports jumbo frames. Just because the
>>> switch will accept and process a 9000 mtu frame, doesnt mean the
>>> computer has to send a 9000 mtu frame. A very common scenario in the
>>> real world.
>>>
>>> [1] https://review.openstack.org/#/c/310448/
>>>
>>
>> Hi Sam,
>>
>> Out of curiosity, in what scenarios is it better to limit the instance's
>> MTU to a value lower than that of the maximum path MTU of the
>> infrastructure? In other words, if the infrastructure supports jumbo
>> frames, why artificially limit an instance's MTU to 1500 if that instance
>> could theoretically communicate with other instances in the same
>> infrastructure via a higher MTU?
>>
>> Hey Jay,
>
> A not-so-uncommon way to setup networks in neutron involves the use of 1:1
> NATs. You have a firewall device that holds real, valid public addresses
> that map to private addresses (RFC-1918). So to OpenStack the network
> appears as a private network, but some of those address map to public
> addresses outside of OpenStack's sphere of knowledge. This works really,
> really well when you have multiple separate ranges of public ip addresses
> and separate gateways for each and you want to use them without creating
> multiple subnets on an external network with OpenStack. This has been
> written about in blog posts [1] and used in enterprise environments (it is
> what Rackspace does for their private cloud [2]).
>
> In this situation, since you are mapping real-ips and the real world runs
> on 1500 mtu, you want to make sure your MTUs match in ways that cannot be
> auto-discovered. A good way to do this is to just use the default 1500 mtu
> for every instance and ensure that that never fragments (which means at
> least 1550 mtu networks for vxlan). So in this case you would have setup
> your network in such a way that a 1500 mtu frame from the internet can
> arrive at your instance without ever being fragment, and outgoing traffic
> isn't trying to send >1500mtu packets into the real internet.
>
> Additionally, there may be other services using the interface (it is not
> dedicated to just neutron traffic) such as ceph which loves high MTUs. I
> mention this as a secondary point because neutron doesn't affect this at
> all, but it is 

[openstack-dev] Mascot/logo for your project

[Heidi Joy Tretheway]

Answering a few questions: 
Snip: "Just a little strange for a community-driven open source project to be 
replacing community-created mascots with top-down designs. I'm not terribly 
opposed to it, but would have definitely preferred if this had come across as a 
request instead of a mandate. I think it's cool and unique that the Ironic 
mascot was designed/drawn by one of our more prolific contributors (Lucas), and 
we'll lose some of that shine with a less-unique logo.”
This is a request, not a mandate - you’re not required to choose a mascot. :-) 
We’re alerting you to the design resource that’s now available to you. We’ve 
done our best to honor community preferences by giving those projects with 
existing mascots priority to keep them. Because illustration styles vary 
widely, having a single illustrator allows us to create branding consistency 
while still keeping the content (mascot) unique to the project and chosen by 
the project team. We also reached out to PTLs last week to ask for 
questions/concerns.
I think we could all be easily bribed if the foundation provided copious 
amounts of stickers to contributors with the new mascot designs on them. :P
There are stickers in the works for sure! And I hope to create some additional 
awesomeness, depending on budget.

What if a project doesn't come up with a mascot? Does the Foundation pick one 
for that project?

If you don’t select a mascot, don’t worry—we won’t pick one for you. We’ll be 
happy to create a text-only treatment of just your project name. Our intent is 
to use the logos across openstack.org, Summit branding, and other marketing 
materials to promote your project. You’ll also get the image file and you can 
use it in your presentations or to create more swag if you like. 

Overall, the response to this has been hugely positive and we have more than 
half of project PTLs responding so far. More questions are very welcome. 

__
Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769  |  skype: heidi.tretheway





__
OpenStack Development Mailing List (not for 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 and MTU advertisements -- post newton

[Chris Friesen]

On 07/11/2016 10:39 AM, Jay Pipes wrote:


Out of curiosity, in what scenarios is it better to limit the instance's MTU to
a value lower than that of the maximum path MTU of the infrastructure? In other
words, if the infrastructure supports jumbo frames, why artificially limit an
instance's MTU to 1500 if that instance could theoretically communicate with
other instances in the same infrastructure via a higher MTU?


It is my understanding that using the max path MTU is ideal, but that not all 
software does path MTU discovery.  Also, some badly-designed security devices 
can mess up PMTUD.


Chris

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

[openstack-dev] Singing in Barcelona

[Neil Jerram]

 I know it's crazy, but I've talked with a few people in Vancouver, Tokyo and Austin about the idea of getting a singing group together during a summit, and they've all encouraged me to go for it - so I'll start to look silly if I don't even try this... :-)So this is a call for anyone who wants to do some singing in Barcelona. I don't yet know who, what, or how we'll perform, but I've created an etherpad:https://etherpad.openstack.org/p/barcelona-singingPlease do contribute there if interested! As with everything in OpenStack, it's important for this to be inclusive, so please don't exclude yourself by assuming anything about style of music or required abilities - feel free to add whatever your ideas and interests might be.       Neil 

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

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

[Matt Riedemann]

On 7/11/2016 10:00 AM, Heidi Joy Tretheway wrote:

The Foundation would like to help promote OpenStack projects in the big
tent with branding and marketing services. The idea is to create a
family of logos for OpenStack projects that are unique, yet immediately
identifiable as part of OpenStack. We’ll be using these logos to promote
your project on the OpenStack website, at the Summit and in marketing
materials.

We’re asking project teams to choose a mascot to represent as their
logo. Your team can select your own mascot, and then we’ll have an
illustrator create the logo for you (and we also plan to print some
special collateral for your team in Barcelona).

If your team already has a logo based on a mascot from nature, you’ll
have first priority to keep that mascot, and the illustrator will
restyle it to be consistent with the other projects. If you have a logo
that doesn’t have a mascot from nature, we encourage your team to choose
a mascot.

Here’s an FAQ and examples of what the logos can look like:
http://www.openstack.org/project-mascots
We’ve also recorded a quick video with an overview of the project:
https://youtu.be/LOdsuNr2T-o

You can get in touch with your PTL to participate in the logo choice
discussion. If you have more questions, I’m happy to help. :-)

Cheers,
Heidi Joy

__
Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769  |  skype: heidi.tretheway







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



What if a project doesn't come up with a mascot? Does the Foundation 
pick one for that project?


--

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] Mascot/logo for your project

[Steve Martinelli]

snip

On Mon, Jul 11, 2016 at 1:15 PM, Jay Faulkner  wrote:
>
>
> I think we could all be easily bribed if the foundation provided copious
> amounts of stickers to contributors with the new mascot designs on them. :P
>

I'm sure that can be arranged :]
__
OpenStack Development Mailing List (not for 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 and MTU advertisements -- post newton

[Sam Yaple]

On Mon, Jul 11, 2016 at 4:39 PM, Jay Pipes  wrote:

> On 07/11/2016 07:45 AM, Sam  Yaple wrote:
>
>> Hello,
>>
>> There was alot of work to get MTU advertisement working well in Mitaka.
>> With the work that was done we can finally have 1500 mtu networks for
>> tunneled networks if the underlying infrastructure supports jumbo frames.
>>
>> Its fantastic for people who have 1500 mtu networks and want to use
>> vxlan, no more hacks to get the instance to use 1450 mtu. Its fantastic
>> for people who want to use 1500+ networks and get the instances setup
>> with 9000 mtu interfaces. Its is not good for people who want consistent
>> mtu no matter the network type. But thats fine, since mtu advertisement
>> _could_ be disabled. Its a fantastic default to have it turned on.
>>
>> With a recent patchset [1] the ability to turn off MTU advertisements
>> was deprecated in Newton. In the review it was stated there is no valid
>> use case for it. I disagree.
>>
>> The scenario is the infrastructure has jumbo frames enabled, but I do
>> not want the instances to be using jumbo frames, but I want them to be
>> using the default 1500 mtu that the rest of the world operates on. This
>> would still setup all of the virtual switching infrastructure to the
>> correct MTUs, but not try to adjust the instances MTUs. In this way the
>> instances are only communicating at 1500 mtu, but never having to
>> fragment/drop inside of the SDN when communicating with other networks
>> even if it is a VXLAN or other tunneled network.
>>
>> Without the option to disable mtu advertisement, inside the same
>> environment flat/vlan and gre/vxlan network will always have different
>> mtu, even if the backend supports jumbo frames.
>>
>> My ask is we keep the advertise_mtu option, and keep it enabled by
>> default. This would allow for the default, common 1500 mtu across
>> networks of different types.
>>
>> This scenario would be very similiar to having a computer with 1500 mtu
>> attached to a switch which supports jumbo frames. Just because the
>> switch will accept and process a 9000 mtu frame, doesnt mean the
>> computer has to send a 9000 mtu frame. A very common scenario in the
>> real world.
>>
>> [1] https://review.openstack.org/#/c/310448/
>>
>
> Hi Sam,
>
> Out of curiosity, in what scenarios is it better to limit the instance's
> MTU to a value lower than that of the maximum path MTU of the
> infrastructure? In other words, if the infrastructure supports jumbo
> frames, why artificially limit an instance's MTU to 1500 if that instance
> could theoretically communicate with other instances in the same
> infrastructure via a higher MTU?
>
> Hey Jay,

A not-so-uncommon way to setup networks in neutron involves the use of 1:1
NATs. You have a firewall device that holds real, valid public addresses
that map to private addresses (RFC-1918). So to OpenStack the network
appears as a private network, but some of those address map to public
addresses outside of OpenStack's sphere of knowledge. This works really,
really well when you have multiple separate ranges of public ip addresses
and separate gateways for each and you want to use them without creating
multiple subnets on an external network with OpenStack. This has been
written about in blog posts [1] and used in enterprise environments (it is
what Rackspace does for their private cloud [2]).

In this situation, since you are mapping real-ips and the real world runs
on 1500 mtu, you want to make sure your MTUs match in ways that cannot be
auto-discovered. A good way to do this is to just use the default 1500 mtu
for every instance and ensure that that never fragments (which means at
least 1550 mtu networks for vxlan). So in this case you would have setup
your network in such a way that a 1500 mtu frame from the internet can
arrive at your instance without ever being fragment, and outgoing traffic
isn't trying to send >1500mtu packets into the real internet.

Additionally, there may be other services using the interface (it is not
dedicated to just neutron traffic) such as ceph which loves high MTUs. I
mention this as a secondary point because neutron doesn't affect this at
all, but it is related to your question.

[1] http://dachary.org/?p=2466
[2] https://developer.rackspace.com/blog/neutron-networking-l3-agent/

Sorry if my question is poorly worded. I'm no networking expert and am
> genuinely curious here. :)
>
> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

[Jay Faulkner]

On Jul 11, 2016, at 8:51 AM, Steve Martinelli 
> wrote:

The keystone project was one of the first to have a logo and I'm more than 
happy to give it up for the sake of a consistent message across all OpenStack 
projects.

I think it's fine if ironic and tripleo want to stick with their current 
animals (luckily they are using logos that meet the new criteria proposed by 
the foundation), but I don't think it's unreasonable if the foundation proposes 
a re-design of existing logos that is more consistent with the rest of the new 
ones.

The logos we use today are too different from each other, i don't think anyone 
would disagree with that. If each project goes off and does their own thing it 
comes off as inconsistent.


Just a little strange for a community-driven open source project to be 
replacing community-created mascots with top-down designs. I'm not terribly 
opposed to it, but would have definitely preferred if this had come across as a 
request instead of a mandate. I think it's cool and unique that the Ironic 
mascot was designed/drawn by one of our more prolific contributors (Lucas), and 
we'll lose some of that shine with a less-unique logo.

I think we could all be easily bribed if the foundation provided copious 
amounts of stickers to contributors with the new mascot designs on them. :P

Thanks,
Jay

stevemar

On Mon, Jul 11, 2016 at 11:33 AM, Steven Hardy 
> wrote:
On Mon, Jul 11, 2016 at 08:00:29AM -0700, Heidi Joy Tretheway wrote:
>The Foundation would like to help promote OpenStack projects in the big
>tent with branding and marketing services. The idea is to create a family
>of logos for OpenStack projects that are unique, yet immediately
>identifiable as part of OpenStack. Weâ**ll be using these logos to promote
>your project on the OpenStack website, at the Summit and in marketing
>materials.
>Weâ**re asking project teams to choose a mascot to represent as their
>logo. Your team can select your own mascot, and then weâ**ll have an
>illustrator create the logo for you (and we also plan to print some
>special collateral for your team in Barcelona).
>If your team already has a logo based on a mascot from nature, youâ**ll
>have first priority to keep that mascot, and the illustrator will restyle
>it to be consistent with the other projects. If you have a logo that
>doesnâ**t have a mascot from nature, we encourage your team to choose a
>mascot.
>Hereâ**s an FAQ and examples of what the logos can look like:
>http://www.openstack.org/project-mascots
>Weâ**ve also recorded a quick video with an overview of the project:
>https://youtu.be/LOdsuNr2T-o
>You can get in touch with your PTL to participate in the logo choice
>discussion. If you have more questions, Iâ**m happy to help. :-)

TripleO has had some discussion already around a project mascot, and we've
settled on the owl logo displayed on tripleo.org and our 
launchpad org:

http://tripleo.org/
https://bugs.launchpad.net/tripleo/

(There is also a hi-res version or SVG around, I just can't find it atm)

This was discussed in the community and accepted here:

http://lists.openstack.org/pipermail/openstack-dev/2016-March/089043.html

Which was in turn based on a previous design discussed here:

http://lists.openstack.org/pipermail/openstack-dev/2015-September/075649.html

So, I think it's likely (unless anyone objects) we'll stick with that
current owl theme for our official mascot.

Overall I like the idea of encouraging official mascots/logos for projects,
quite a few have done so informally and I think it's a fun way to reinforce
project/team identity within the OpenStack community.

Thanks!

Steve Hardy

__
OpenStack Development Mailing List (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] Mascot/logo for your project

[Dmitry Tantsur]

On 07/11/2016 05:51 PM, Steve Martinelli wrote:

The keystone project was one of the first to have a logo and I'm more
than happy to give it up for the sake of a consistent message across all
OpenStack projects.

I think it's fine if ironic and tripleo want to stick with their current
animals (luckily they are using logos that meet the new criteria
proposed by the foundation), but I don't think it's unreasonable if the
foundation proposes a re-design of existing logos that is more
consistent with the rest of the new ones.


Lets see how it ends up :)



The logos we use today are too different from each other, i don't think
anyone would disagree with that. If each project goes off and does their
own thing it comes off as inconsistent.


I don't think I value consistency in mascots too much, but we'll see.



stevemar

On Mon, Jul 11, 2016 at 11:33 AM, Steven Hardy > wrote:

On Mon, Jul 11, 2016 at 08:00:29AM -0700, Heidi Joy Tretheway wrote:
>The Foundation would like to help promote OpenStack projects in the big
>tent with branding and marketing services. The idea is to create a 
family
>of logos for OpenStack projects that are unique, yet immediately
>identifiable as part of OpenStack. Weâ**ll be using these logos
to promote
>your project on the OpenStack website, at the Summit and in marketing
>materials.
>Weâ**re asking project teams to choose a mascot to represent as
their
>logo. Your team can select your own mascot, and then weâ**ll
have an
>illustrator create the logo for you (and we also plan to print some
>special collateral for your team in Barcelona).
>If your team already has a logo based on a mascot from nature,
youâ**ll
>have first priority to keep that mascot, and the illustrator will 
restyle
>it to be consistent with the other projects. If you have a logo that
>doesnâ**t have a mascot from nature, we encourage your team to
choose a
>mascot.
>Hereâ**s an FAQ and examples of what the logos can look like:
>http://www.openstack.org/project-mascots
>Weâ**ve also recorded a quick video with an overview of the
project:
>https://youtu.be/LOdsuNr2T-o
>You can get in touch with your PTL to participate in the logo choice
>discussion. If you have more questions, Iâ**m happy to help. :-)

TripleO has had some discussion already around a project mascot, and
we've
settled on the owl logo displayed on tripleo.org
 and our launchpad org:

http://tripleo.org/
https://bugs.launchpad.net/tripleo/

(There is also a hi-res version or SVG around, I just can't find it atm)

This was discussed in the community and accepted here:

http://lists.openstack.org/pipermail/openstack-dev/2016-March/089043.html

Which was in turn based on a previous design discussed here:


http://lists.openstack.org/pipermail/openstack-dev/2015-September/075649.html

So, I think it's likely (unless anyone objects) we'll stick with that
current owl theme for our official mascot.

Overall I like the idea of encouraging official mascots/logos for
projects,
quite a few have done so informally and I think it's a fun way to
reinforce
project/team identity within the OpenStack community.

Thanks!

Steve Hardy

__
OpenStack Development Mailing List (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][calico] New networking-calico IRC meeting

[Neil Jerram]

Hi all,

Just a quick reminder: the first networking-calico IRC meeting will be
tomorrow (12th July) at 1600 UTC.

Neil


On Fri, Jul 1, 2016 at 12:31 PM Neil Jerram  wrote:

> The first networking-calico IRC meeting was planned for 28th June, but I'm
> afraid I was unwell - so it will now be 12th July.  I've updated the agenda
> [2] accordingly.
>
> Neil
>
>
> On Mon, Jun 20, 2016 at 3:42 PM Neil Jerram  wrote:
>
>> Calling everyone interested in networking-calico ...!  networking-calico
>> has been around in the Neutron stadium for a while now, and it's way past
>> time that we had a proper forum for discussing and evolving it - so I'm
>> happy to be finally proposing a regular IRC meeting slot for it: [1].  A
>> strawman initial agenda is up at [2].
>>
>> [1] https://review.openstack.org/#/c/331689/
>> [2] https://wiki.openstack.org/wiki/Meetings/NetworkingCalico
>>
>> Please do take a look and
>>
>>- let me know your views on the timing, either here or on the review
>>- feel free to add items to the agenda.
>>
>>
>> Many thanks,
>>Neil
>>
>>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Neutron and MTU advertisements -- post newton

[Jay Pipes]

On 07/11/2016 07:45 AM, Sam  Yaple wrote:

Hello,

There was alot of work to get MTU advertisement working well in Mitaka.
With the work that was done we can finally have 1500 mtu networks for
tunneled networks if the underlying infrastructure supports jumbo frames.

Its fantastic for people who have 1500 mtu networks and want to use
vxlan, no more hacks to get the instance to use 1450 mtu. Its fantastic
for people who want to use 1500+ networks and get the instances setup
with 9000 mtu interfaces. Its is not good for people who want consistent
mtu no matter the network type. But thats fine, since mtu advertisement
_could_ be disabled. Its a fantastic default to have it turned on.

With a recent patchset [1] the ability to turn off MTU advertisements
was deprecated in Newton. In the review it was stated there is no valid
use case for it. I disagree.

The scenario is the infrastructure has jumbo frames enabled, but I do
not want the instances to be using jumbo frames, but I want them to be
using the default 1500 mtu that the rest of the world operates on. This
would still setup all of the virtual switching infrastructure to the
correct MTUs, but not try to adjust the instances MTUs. In this way the
instances are only communicating at 1500 mtu, but never having to
fragment/drop inside of the SDN when communicating with other networks
even if it is a VXLAN or other tunneled network.

Without the option to disable mtu advertisement, inside the same
environment flat/vlan and gre/vxlan network will always have different
mtu, even if the backend supports jumbo frames.

My ask is we keep the advertise_mtu option, and keep it enabled by
default. This would allow for the default, common 1500 mtu across
networks of different types.

This scenario would be very similiar to having a computer with 1500 mtu
attached to a switch which supports jumbo frames. Just because the
switch will accept and process a 9000 mtu frame, doesnt mean the
computer has to send a 9000 mtu frame. A very common scenario in the
real world.

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


Hi Sam,

Out of curiosity, in what scenarios is it better to limit the instance's 
MTU to a value lower than that of the maximum path MTU of the 
infrastructure? In other words, if the infrastructure supports jumbo 
frames, why artificially limit an instance's MTU to 1500 if that 
instance could theoretically communicate with other instances in the 
same infrastructure via a higher MTU?


Sorry if my question is poorly worded. I'm no networking expert and am 
genuinely curious here. :)


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] [Nova][libvirt]Could not create tap interface in ovs bridge

[amll]

Hi,

I think I am having the same problem, did you manage to solve it?

Thanks in advance,

Arturo Mayoral.

El 10/01/16 a las 13:28, manda phaneendra escribió:

Hi,
When i am spawning a new VM, there is an error in neutron conductor
"error: Unable to add port tapc3b3f80b-ee to OVS bridge br-int"

When the issue is analyzed further, have seen error in libvirt logs,
"libvirt:  error : cannot execute binary ovs-vsctl: Permission denied"
and
 error : virNetDevOpenvswitchAddPort:155 : internal error: Unable to 
add port tap1ffb7f48-81 to OVS bridge br-int


After installing the OVS patch, ovs-vsctl is installed in /usr/local/bin

Please help me how to solve this problem.

--
Thanks & regards,
Phaneendra Manda.
ph: +91 9972 622 741
Email:mphaneen...@gmail.com 


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


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

[openstack-dev] [TripleO] Deep Dive Thursday July 14 1400UTC

[James Slagle]

As a reminder, we will have a deep dive on Thursday July 14th at 1400
UTC. Steve Hardy has volunteered to go into tripleo-heat-templates and
the software configuration workflows.

Further details are in the etherpad (along with a link to last week's
recording if you missed it):
https://etherpad.openstack.org/p/tripleo-deep-dive-topics

If you have specific things you'd like to see covered, either on
Thursday or on a later week, please add them to the etherpad.

-- 
-- James Slagle
--

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

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

[Steve Martinelli]

The keystone project was one of the first to have a logo and I'm more than
happy to give it up for the sake of a consistent message across all
OpenStack projects.

I think it's fine if ironic and tripleo want to stick with their current
animals (luckily they are using logos that meet the new criteria proposed
by the foundation), but I don't think it's unreasonable if the foundation
proposes a re-design of existing logos that is more consistent with the
rest of the new ones.

The logos we use today are too different from each other, i don't think
anyone would disagree with that. If each project goes off and does their
own thing it comes off as inconsistent.

stevemar

On Mon, Jul 11, 2016 at 11:33 AM, Steven Hardy  wrote:

> On Mon, Jul 11, 2016 at 08:00:29AM -0700, Heidi Joy Tretheway wrote:
> >The Foundation would like to help promote OpenStack projects in the
> big
> >tent with branding and marketing services. The idea is to create a
> family
> >of logos for OpenStack projects that are unique, yet immediately
> >identifiable as part of OpenStack. Weâ**ll be using these logos to
> promote
> >your project on the OpenStack website, at the Summit and in marketing
> >materials.
> >Weâ**re asking project teams to choose a mascot to represent as their
> >logo. Your team can select your own mascot, and then weâ**ll have an
> >illustrator create the logo for you (and we also plan to print some
> >special collateral for your team in Barcelona).
> >If your team already has a logo based on a mascot from nature,
> youâ**ll
> >have first priority to keep that mascot, and the illustrator will
> restyle
> >it to be consistent with the other projects. If you have a logo that
> >doesnâ**t have a mascot from nature, we encourage your team to choose
> a
> >mascot.
> >Hereâ**s an FAQ and examples of what the logos can look like:
> >http://www.openstack.org/project-mascots
> >Weâ**ve also recorded a quick video with an overview of the project:
> >https://youtu.be/LOdsuNr2T-o
> >You can get in touch with your PTL to participate in the logo choice
> >discussion. If you have more questions, Iâ**m happy to help. :-)
>
> TripleO has had some discussion already around a project mascot, and we've
> settled on the owl logo displayed on tripleo.org and our launchpad org:
>
> http://tripleo.org/
> https://bugs.launchpad.net/tripleo/
>
> (There is also a hi-res version or SVG around, I just can't find it atm)
>
> This was discussed in the community and accepted here:
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089043.html
>
> Which was in turn based on a previous design discussed here:
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/075649.html
>
> So, I think it's likely (unless anyone objects) we'll stick with that
> current owl theme for our official mascot.
>
> Overall I like the idea of encouraging official mascots/logos for projects,
> quite a few have done so informally and I think it's a fun way to reinforce
> project/team identity within the OpenStack community.
>
> Thanks!
>
> Steve Hardy
>
> __
> OpenStack Development Mailing List (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] Mascot/logo for your project

[Steven Hardy]

On Mon, Jul 11, 2016 at 08:00:29AM -0700, Heidi Joy Tretheway wrote:
>The Foundation would like to help promote OpenStack projects in the big
>tent with branding and marketing services. The idea is to create a family
>of logos for OpenStack projects that are unique, yet immediately
>identifiable as part of OpenStack. Weâ**ll be using these logos to promote
>your project on the OpenStack website, at the Summit and in marketing
>materials.  
>Weâ**re asking project teams to choose a mascot to represent as their
>logo. Your team can select your own mascot, and then weâ**ll have an
>illustrator create the logo for you (and we also plan to print some
>special collateral for your team in Barcelona). 
>If your team already has a logo based on a mascot from nature, youâ**ll
>have first priority to keep that mascot, and the illustrator will restyle
>it to be consistent with the other projects. If you have a logo that
>doesnâ**t have a mascot from nature, we encourage your team to choose a
>mascot.
>Hereâ**s an FAQ and examples of what the logos can look like:
>http://www.openstack.org/project-mascots
>Weâ**ve also recorded a quick video with an overview of the project:
>https://youtu.be/LOdsuNr2T-o
>You can get in touch with your PTL to participate in the logo choice
>discussion. If you have more questions, Iâ**m happy to help. :-)

TripleO has had some discussion already around a project mascot, and we've
settled on the owl logo displayed on tripleo.org and our launchpad org:

http://tripleo.org/
https://bugs.launchpad.net/tripleo/

(There is also a hi-res version or SVG around, I just can't find it atm)

This was discussed in the community and accepted here:

http://lists.openstack.org/pipermail/openstack-dev/2016-March/089043.html

Which was in turn based on a previous design discussed here:

http://lists.openstack.org/pipermail/openstack-dev/2015-September/075649.html

So, I think it's likely (unless anyone objects) we'll stick with that
current owl theme for our official mascot.

Overall I like the idea of encouraging official mascots/logos for projects,
quite a few have done so informally and I think it's a fun way to reinforce
project/team identity within the OpenStack community.

Thanks!

Steve Hardy

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

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

[Alex Xu]

Matt mentioned Aggregate in the scheduler meeting, that is good question
and also reminder me I should explain the relationship between Aggregate
and ResourceProviderTags.

The Aggregate is expected to keep as a tool for group the hosts, and just
for group hosts. People used to manage Capabilities with Aggregates, they
put the hosts with some kind of Capabilities into same Aggregates, and
using the metadata to identify the Capabilities. But Aggregate with
metadata is really not very easy to manage.

Thinking of the case:

Host1 have Capability1
Host2 have Capability1 and Capability2
Host3 have Capability2 and Capability3.

With this case, we needs 3 aggregates for each Capability: agg_cap1,
agg_cap2, agg_cap3. Then we needs add hosts to the aggregate as below:

agg_cap1: host1, host2
agg_cap2: host2, host3
agg_cap3: host3

When there are more capabilities and more hosts which needs to manage, the
mapping of hosts and aggregate will be more complicate. And there isn't a
easy interface to let user to know the specific host have what kind of
capabilities.

The ResourceProviderTags will be a substitution of Aggregate on manage
capabilities. With tags, it won't generate a complex mapping.

For the same case, we just need to add tags on the ResourceProvider. The
interface of tags is pretty easy, check out the api-wg guideline
https://github.com/openstack/api-wg/blob/master/guidelines/tags.rst. And
the query parameter made the management easy.

There are also have some user want to write script to manage the
Capabilities. Thinking the aggregate, the script will be very hard due to
manage the mapping between aggregates and hosts. The script will be very
easy with tags, due to tags just a set of string.


2016-07-11 19:08 GMT+08:00 Alex Xu :

> This propose is about using ResourceProviderTags as a solution to manage
> Capabilities (Qualitative) in ResourceProvider.
> The ResourceProviderTags is to describe the capabilities which are defined
> by OpenStack Service (Compute Service,
> Storage Service, Network Service etc.) and by users. The ResourceProvider
> provide resource exposed by a single
> compute node, some shared resource pool or an external resource-providing
> service of some sort.  As such,
> ResourceProviderTags is also expected to describe the capabilities of
> single ResourceProvider or the capabilities of
> ResourcePool.
>
> The ResourceProviderTags is similar with ServersTags [0] which is
> implemented in the Nova. The only difference is
> that the tags is attached to the ResourceProvider. The API endpoint will
> be " /ResourceProvider/{uuid}/tags", and it
> will follow the API-WG guideline about Tags [1].
>
> As the Tags are just strings, the meaning of Tag isn't defined by
> Scheduler. The meaning of Tag is defined by
> OpenStack services or Users. The ResourceProviderTags will only be used
> for scheduling with a ResourceProviderTags
> filter.
>
> The ResourceProviderTags is very easy to cover the cases of single
> ResourceProvider, ResourcePool and
> DynamicResouces. Let see those cases one by one.
>
> For single ResourceProvider case, just see how Nova report ComputeNode's
> Capabilities. Firstly,  Nova is expected
> to define a standard way to describe the Capabilities which provided by
> Hypervisor or Hardware. Then those description
> of Capabilities can be used across the Openstack deployment. So Nova will
> define a set of Tags. Those Tags should
> be included with prefix to indicated that this is coming from Nova. Also
> the naming rule of prefix can be used to catalog
> the Capabilities. For example, the capabilities can be defined as:
>
> COMPUTE_HW_CAP_CPU_AVX
> COMPUTE_HW_CAP_CPU_SSE
> 
> COMPUTE_HV_CAP_LIVE_MIGRATION
> COMPUTE_HV_CAP_LIVE_SNAPSHOT
> 
>
> ( The COMPUTE means this is coming from Nova. HW means this is hardware
> related Capabilities. HV means this is
>  capabilities of Hypervisor. But the catalog of Capabilities can be
> discussed separated. This propose focus on the
>  ResourceTags. We also have another idea about not using 'PREFIX' to
> manage the Tags. We can add attributes to the
>  Tags. Then we have more control on the Tags. This will describe
> separately in the bottom. )
>
> Nova will create ResourceProvider for the compute node, and report the
> quantitative stuff, and report capabilities
> by adding those defined tags to the ResourceProvider at same time. Then
> those Capabilities are exposed by Nova
> automatically.
>
> The capabilities of ComputeNode can be queried through the API "GET
> /ResourceProviders/{uuid}/tags".
>
> For the ResourcePool case, let us use Shared Storage Pool as example. The
> different Storage Pool may have
> different capabilities. Maybe one of Pool are using SSD. For expose that
> Capability, admin user can do as below:
>
> 1. Define the aggregates
>   $AGG_UUID=`openstack aggregate create r1rck0610`
>
> 2. Create resource pool for shared storage
>   $RP_UUID=`openstack 

[openstack-dev] [new][openstack] osc-lib 0.3.0 release (newton)

[no-reply]

We are excited to announce the release of:

osc-lib 0.3.0: OpenStackClient Library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in osc-lib 0.2.1..0.3.0
---

572f3ee Updated from global requirements
abc8240 Generate auth plugin options based on the name
ed86f63 Remove tempest from test-requirements.txt
505c427 Don't create a requests.Session for session
7e21c0c Remove old fakes
051f8f4 Updated from global requirements
a8ce81c Make OSC_Config the default


Diffstat (except docs and test files)
-

osc_lib/api/auth.py |  70 +--
osc_lib/clientmanager.py|  29 +--
osc_lib/shell.py|   7 +-
requirements.txt|   3 +-
test-requirements.txt   |   1 -
9 files changed, 520 insertions(+), 587 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 00aad52..dd1641f 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12,2 +12 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
-requests>=2.10.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 7175fea..d000a8a 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -18 +17,0 @@ testtools>=1.4.0 # MIT
-tempest>=11.0.0 # Apache-2.0



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

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

[Dmitry Tantsur]

On 07/11/2016 05:00 PM, Heidi Joy Tretheway wrote:

The Foundation would like to help promote OpenStack projects in the big
tent with branding and marketing services. The idea is to create a
family of logos for OpenStack projects that are unique, yet immediately
identifiable as part of OpenStack. We’ll be using these logos to promote
your project on the OpenStack website, at the Summit and in marketing
materials.

We’re asking project teams to choose a mascot to represent as their
logo. Your team can select your own mascot, and then we’ll have an
illustrator create the logo for you (and we also plan to print some
special collateral for your team in Barcelona).


Ironic has had a mascot for quite some time, it can be found on 
https://wiki.openstack.org/wiki/Ironic (see in the bottom).




If your team already has a logo based on a mascot from nature, you’ll
have first priority to keep that mascot, and the illustrator will
restyle it to be consistent with the other projects. If you have a logo
that doesn’t have a mascot from nature, we encourage your team to choose
a mascot.

Here’s an FAQ and examples of what the logos can look like:
http://www.openstack.org/project-mascots
We’ve also recorded a quick video with an overview of the project:
https://youtu.be/LOdsuNr2T-o

You can get in touch with your PTL to participate in the logo choice
discussion. If you have more questions, I’m happy to help. :-)

Cheers,
Heidi Joy

__
Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769  |  skype: heidi.tretheway







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




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

[openstack-dev] [new][ironic] ironic-lib 2.0.0 release (newton)

[no-reply]

We are satisfied to announce the release of:

ironic-lib 2.0.0: Ironic common library

This release is part of the newton release series.

With package available at:

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

For more details, please see below.

Changes in ironic-lib 1.3.0..2.0.0
--

9b5cb20 Include wipefs --force option
9fea533 Updated from global requirements
433f3d9 Add keyword arg 'log_stdout' to utils.execute()
3858f60 Remove releasenotes/*
e61a45b Use autospec in mocked objects
fb46000 Add support for metrics
122891b Ignore .idea folder
aeaa70b Updated from global requirements
f7a6100 Updated from global requirements
cd25d69 Updated from global requirements
2ca50bc Remove deprecated disk util configs
1d2f962 Updated from global requirements
c6d4f0f Add support for BIOS local boot for GPT label
28b1941 Clarify which projects are meant to use the ironic-lib
c693f1e Fix coverage option and execution


Diffstat (except docs and test files)
-

.gitignore|   1 +
README.rst|   3 +-
ironic_lib/disk_partitioner.py|  13 +-
ironic_lib/disk_utils.py  |  47 +++--
ironic_lib/exception.py   |   4 +
ironic_lib/metrics.py | 300 ++
ironic_lib/metrics_statsd.py  | 108 +++
ironic_lib/metrics_utils.py   | 100 ++
ironic_lib/utils.py   |  21 ++-
requirements.txt  |  10 +-
setup.cfg |   2 +
test-requirements.txt |   4 +-
tox.ini   |   2 +-
19 files changed, 1091 insertions(+), 87 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 4bd9546..1159ddb 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6,2 +6,2 @@ pbr>=1.6 # Apache-2.0
-oslo.concurrency>=3.5.0 # Apache-2.0
-oslo.config>=3.9.0 # Apache-2.0
+oslo.concurrency>=3.8.0 # Apache-2.0
+oslo.config>=3.10.0 # Apache-2.0
@@ -9,3 +9,3 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.service>=1.0.0 # Apache-2.0
-oslo.utils>=3.5.0 # Apache-2.0
-requests!=2.9.0,>=2.8.1 # Apache-2.0
+oslo.service>=1.10.0 # Apache-2.0
+oslo.utils>=3.14.0 # Apache-2.0
+requests>=2.10.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index c96af19..6a7c98a 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8,2 +8,2 @@ hacking<0.11,>=0.10.0
-mock>=1.2 # BSD
-os-testr>=0.4.1 # Apache-2.0
+mock>=2.0 # BSD
+os-testr>=0.7.0 # Apache-2.0



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

Re: [openstack-dev] [mistral][osc-lib][openstackclient] is it too early for orc-lib?

[Dean Troyer]

On Mon, Jul 11, 2016 at 9:24 AM, Dmitry Tantsur  wrote:

> It seems like OSC now issues warnings if we use bits that are moved to
> osc-lib. Does it mean that now osc-lib is ready for all projects to switch
> to? If not, could you please revert the warnings? It's a bit confusing if
> we should our users warnings that we can't fix.
>

This only happens in OSC trunk, which will be released as 3.0.0 soon.  At
that point, osc-lib will also be released as 1.0 and be considered stable
and ready for general use.

dt

-- 

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

[openstack-dev] [new][ironic] ironic-python-agent 1.4.0 release (newton)

[no-reply]

We are content to announce the release of:

ironic-python-agent 1.4.0: Ironic Python Agent Ramdisk

This release is part of the newton release series.

For more details, please see below.

1.4.0
^


New Features


* Added *ipa-disk-wait-attempts* configuration option to configure
  the number of times to try and check to see if at least one suitable
  disk has appeared in inventory before proceeding with any actions.

* Added *ipa-disk-wait-delay* configuration option to configure how
  many seconds to wait between attempts to check if at least one
  suitable disk has appeared in inventory.

* A new "log" extension has been added and can be used to retrieve
  the system logs via the IPA API.

* Adds new PCI devices collector named "pci_devices" to inspector
  module. Data is gathered from /sys/bus/pci/devices directory and is
  stored under "pci_devices" key as a dictionary containing
  "vendor_id" and "product_id" keys, which then will be used by the
  inspector to distinguish various PCI devices.

* Add support for LLDP data in the returned inventory when option
  collect_lldp is set to True. Each interface returned in the
  inventory that receives an LLDP packet will contain the whole LLDP
  packet represented as a list of TLVs in the field 'lldp'.


Upgrade Notes
*

* Deprecated reserved fields switch_port_descr and
  switch_chassis_descr in favor of returning the whole LLDP packet for
  each interface so that IPA processing of this data remains generic
  and full processing can be customised server side instead of having
  to create custom ramdisks. These fields will be removed in Ocata.


Bug Fixes
*

* The "logs" inspection collector now works with the TinyIPA image.

Changes in ironic-python-agent 1.3.0..1.4.0
---

5df024e Bump CoreOS to 1010.6.0 (last current stable)
f26f902 Replace the ps options when collecting logs
b139dcc Updated from global requirements
af81914 Add a log extension
ff9f0ad Update doc about lookup action
d89dfb1 Documentation follow-up to the LLDP patch
542aa0a Updated from global requirements
f7e080c Add PCI devices collector to inspector
50ddb89 Replace dict.get(key) with dict[key] in tests
a7f0af7 Support LLDP data as part of interfaces in inventory
992b875 tox: Update flake8 to ignore tinyipa imagebuild folders
45e1080 Fix functional tests
1ef8c32 Replace assertRaisesRegexp with assertRaisesRegex
e0e8334 Updated from global requirements
13a8c63 Add configuration options for DISK_WAIT


Diffstat (except docs and test files)
-

imagebuild/coreos/Makefile |   3 +
imagebuild/coreos/coreos-oem-inject.py | 132 +++-
imagebuild/coreos/oem/cloud-config.yml |  18 +++
imagebuild/coreos/pin_latest_coreos.sh |  11 ++
imagebuild/coreos/version.txt  |   7 +
imagebuild/tinyipa/build_files/bootlocal.sh|   2 +-
ironic_python_agent/config.py  |  17 +++
ironic_python_agent/extensions/log.py  |  34 +
ironic_python_agent/hardware.py|  73 +++--
ironic_python_agent/inspector.py   |  72 ++---
ironic_python_agent/utils.py   | 125 +++
...add-disk-wait-config-opts-fe805292baca8029.yaml |   8 +
.../notes/add-log-extension-35ca22cc0709af4c.yaml  |   6 +
.../add-pci-devices-info-3f86934a505d1b31.yaml |   9 ++
...support-lldp-in-inventory-4ab6e45ccd35dace.yaml |  12 ++
requirements.txt   |   2 +-
setup.cfg  |   2 +
test-requirements.txt  |   4 +-
tox.ini|   2 +-
28 files changed, 916 insertions(+), 111 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index fee9750..4d07dea 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -14 +14 @@ oslo.service>=1.10.0 # Apache-2.0
-oslo.utils>=3.11.0 # Apache-2.0
+oslo.utils>=3.14.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 4e9148f..ebe8363 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15 +15 @@ doc8 # Apache-2.0
-sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
+sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
@@ -18 +18 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-reno>=1.6.2 # Apache2
+reno>=1.8.0 # Apache2



__
OpenStack Development Mailing List (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] Mascot/logo for your project

[Heidi Joy Tretheway]

The Foundation would like to help promote OpenStack projects in the big tent 
with branding and marketing services. The idea is to create a family of logos 
for OpenStack projects that are unique, yet immediately identifiable as part of 
OpenStack. We’ll be using these logos to promote your project on the OpenStack 
website, at the Summit and in marketing materials.  

We’re asking project teams to choose a mascot to represent as their logo. Your 
team can select your own mascot, and then we’ll have an illustrator create the 
logo for you (and we also plan to print some special collateral for your team 
in Barcelona). 

If your team already has a logo based on a mascot from nature, you’ll have 
first priority to keep that mascot, and the illustrator will restyle it to be 
consistent with the other projects. If you have a logo that doesn’t have a 
mascot from nature, we encourage your team to choose a mascot. 

Here’s an FAQ and examples of what the logos can look like: 
http://www.openstack.org/project-mascots 

We’ve also recorded a quick video with an overview of the project: 
https://youtu.be/LOdsuNr2T-o   

You can get in touch with your PTL to participate in the logo choice 
discussion. If you have more questions, I’m happy to help. :-)

Cheers,
Heidi Joy

__
Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769  |  skype: heidi.tretheway





__
OpenStack Development Mailing List (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] [Smaug]- IRC Meeting tomorrow (11/07) - 1100 UTC SM,

[Saggi Mizrahi]

Hi All,

We will hold our weekly IRC meeting tomorrow (Tuesday, 11/07) at 1100
UTC in #openstack-smaug

***Please note the time and location change.
Due to scheduling issue we will not be able to have the talk in the
usual time of 1500 UTC and thus will not have a meeting room.
I will try and have the logs pushed manually at a later time.

Please review the proposed meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/smaug

Please feel free to add to the agenda any subject you would like to
discuss.

Thanks,
Saggi
-
This email and any files transmitted and/or attachments with it are 
confidential and proprietary information of
Toga Networks Ltd., and intended solely for the use of the individual or entity 
to whom they are addressed.
If you have received this email in error please notify the system manager. This 
message contains confidential
information of Toga Networks Ltd., and is intended only for the individual 
named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on
the contents of this information is strictly prohibited.



__
OpenStack Development Mailing List (not for 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] [ironic] Input types for scheduler filters

[Miles Gould]

On 08/07/16 15:22, Miles Gould wrote:

On 07/07/16 17:43, Miles Gould wrote:

Further evidence that this isn't the intended behaviour: if you remove
all the calls to str(), then the original tests still pass, but the
' e' (substring matching) one doesn't.


I've now proposed this as a patch:
https://review.openstack.org/#/c/339576/ Please review!


Status update on this: Ruby Loo found a place in nova where the 
thing-being-matched is cast to a string before matching:


https://github.com/openstack/nova/blob/90ec46c87fbf572805c7758377431e26c93622a4/nova/scheduler/filters/compute_capabilities_filter.py#L87

This means  will match substrings and not subsets; we talked 
about this in the nova-scheduler meeting and agreed it's a bug. I'll 
submit a patch to fix it in Nova.


Alexis Lee has submitted a patch to the oslo.utils version to enforce 
the type of the value being matched:


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

There's some discussion about whether this is the right approach, but 
the Oslo cores have made clear that without some type-enforcement the 
code won't be merged into Oslo.


If the matcher code can't be merged into Oslo, we may copy it directly 
into ironic-lib until it can be; understandably, there's some resistance 
to this idea.


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

Reviews on all the above would be much appreciated!

Miles

__
OpenStack Development Mailing List (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 and MTU advertisements -- post newton

[Sam Yaple]

Hello,

There was alot of work to get MTU advertisement working well in Mitaka.
With the work that was done we can finally have 1500 mtu networks for
tunneled networks if the underlying infrastructure supports jumbo frames.

Its fantastic for people who have 1500 mtu networks and want to use vxlan,
no more hacks to get the instance to use 1450 mtu. Its fantastic for people
who want to use 1500+ networks and get the instances setup with 9000 mtu
interfaces. Its is not good for people who want consistent mtu no matter
the network type. But thats fine, since mtu advertisement _could_ be
disabled. Its a fantastic default to have it turned on.

With a recent patchset [1] the ability to turn off MTU advertisements was
deprecated in Newton. In the review it was stated there is no valid use
case for it. I disagree.

The scenario is the infrastructure has jumbo frames enabled, but I do not
want the instances to be using jumbo frames, but I want them to be using
the default 1500 mtu that the rest of the world operates on. This would
still setup all of the virtual switching infrastructure to the correct
MTUs, but not try to adjust the instances MTUs. In this way the instances
are only communicating at 1500 mtu, but never having to fragment/drop
inside of the SDN when communicating with other networks even if it is a
VXLAN or other tunneled network.

Without the option to disable mtu advertisement, inside the same
environment flat/vlan and gre/vxlan network will always have different mtu,
even if the backend supports jumbo frames.

My ask is we keep the advertise_mtu option, and keep it enabled by default.
This would allow for the default, common 1500 mtu across networks of
different types.

This scenario would be very similiar to having a computer with 1500 mtu
attached to a switch which supports jumbo frames. Just because the switch
will accept and process a 9000 mtu frame, doesnt mean the computer has to
send a 9000 mtu frame. A very common scenario in the real world.

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

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

Re: [openstack-dev] [mistral][osc-lib][openstackclient] is it too early for orc-lib?

[Dmitry Tantsur]

On 06/30/2016 11:29 PM, Dean Troyer wrote:

On Thu, Jun 30, 2016 at 8:38 AM, Hardik
> wrote:

Regarding osc-lib we have mainly two changes.

1) Used "utils" which is moved from openstackclient.common.utils to
osc_lib.utils
2) We used "command"  which wrapped in osc_lib from cliff.

So I think there is no harm in keeping osc_lib.


Admittedly the change to include osc-lib is a little early, I would have
preferred until the other parts of it were a bit more stable.


Also, I guess we do not need openstackclient to be installed  with
mistralclient as if mistral is used in standalone mode
there is no need of openstackclient.


The choice to include OSC as a dependency of a plugin/library rests
entirely on the plugin team, and that will usually be determined by the
answer to the question "Do you want all users of your library to have
OSc installed even if they do not use it?"  or alternatively "Do you
want to make your users remember to install OSC after installing the
plugin?"

Note that we do intend to have the capability on osc-lib to build an
OSC-like stand-alone binary for plugins that would theoretically make
installing OSC optional for stand-alone client users.  This is not
complete yet, and as I said above, one reason I wish osc-lib had not
been merged into plugin requirements yet.  That said, as long as you
don't use those bits yet you will be fine, the utils, command, etc bits
are stable, it is the clientmanager and shell parts that are still being
developed.


Dean,

It seems like OSC now issues warnings if we use bits that are moved to 
osc-lib. Does it mean that now osc-lib is ready for all projects to 
switch to? If not, could you please revert the warnings? It's a bit 
confusing if we should our users warnings that we can't fix.


Thanks.



dt

--

Dean Troyer
dtro...@gmail.com 


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




__
OpenStack Development Mailing List (not for 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] Can anyone share some experience for how to configure keystone work with https

[Lance Bragstad]

There are several upstream deployment projects that have SSL support baked
in [0] [1], in case you want to pick through and see exactly how they
deploy keystone with SSL.


[0] https://github.com/openstack/openstack-ansible-os_keystone
[1] https://github.com/openstack/puppet-keystone

On Mon, Jul 11, 2016 at 2:57 AM, Kseniya Tychkova 
wrote:

> Hi,
> just follow instruction for your web server. For example, for Apache  -
> https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
> In short:
> - create certificates
> - install and enable ssl module
> - enable ssl for keystone site (add directives in your
> /etc/apache2/sites-available/keystone-wsgi. conf file)
>
> On Mon, Jul 11, 2016 at 6:22 AM, Jay Lau  wrote:
>
>> Hi,
>>
>> Does anyone have some experience or some document for how to configure
>> keystone work with https? If so, can you please help share with me or show
>> some links that can help?
>>
>> --
>> Thanks,
>>
>> Jay Lau (Guangya Liu)
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][upgrades] Bi-weekly upgrades work status. 7/11/2016

[Korzeniewski, Artur]

Hi,
Starting another round of bi-weekly update presented once in a 3-week time 
period.

Let's kick it:


1.   We are still working on porting existing resources to use OVO
What was merged:

-  objects: Introduce the DNSNameServer OVO in the code: 
https://review.openstack.org/326477

-  Refactor NetworkDhcpAgentBinding: https://review.openstack.org/328452

Still a hot topic for reviews:

-  Introduces ovo objects for security groups 
https://review.openstack.org/284738

-  objects: Adjust Subnet fields, add tenant_id and segment_id 
https://review.openstack.org/331009

-  objects: Add RBAC to Subnet OVO https://review.openstack.org/337634

-  objects: Add update_fields method in base class. 
https://review.openstack.org/337539

-  objects: better apply filters for objects/db/api/get_object query. 
https://review.openstack.org/334381

-  objects: loading synthetic fields from defined ORM relationships. 
https://review.openstack.org/334380

-  Allow unique keys to be used with get_object 
https://review.openstack.org/322024


During integration of subnet object, new requirement has been identified - 
increasing the number of objects should not influence on number of queries to 
DB. Current implementation of objects in neutron handles relationship by 
loading each required subobject with another query. But when using query 
formatting from common_db_mixin code, there is no need to load the related 
object (called synthetic fields in NeutronDbObject), since they are already 
fetch with main object. The patch


During integration of subnet object, I have found a requirement to use only one 
sql query with usage of side-loaded relationship objects, in order to fulfill 
the performance goals and not to query the DB too often when number of 
resources is increasing.
This means, when we load the object with standard sql query using 
common_db_mixin code, there is no need to load the related object (called 
synthetic fields in NeutronDbObject), since they are already fetch with main 
object.

Please remember the port object, which is still in WIP phase:

-  SUPER WIP OVO port object https://review.openstack.org/253641

Besides the above resources, we have other database models ported to OVO in 
review queue:

-  Flavor and Service Profile to OVO 
https://review.openstack.org/306685/

-  Service Type to OVO https://review.openstack.org/304322

-  DistributedVirtualRouter mac address to OVO 
https://review.openstack.org/304873

-  Agent to OVO https://review.openstack.org/297887

-  objects: introduce NetworkPortSecurity object 
https://review.openstack.org/327257

-  Add OVO for dns Objects https://review.openstack.org/334695

-  Introduce OVO for quotas https://review.openstack.org/338625

Also an important requirement for introducing objects is refactoring to break 
the circular dependency issue, patches:

-  Refactoring Agent DB model https://review.openstack.org/330870/

-  Also the blueprint: https://bugs.launchpad.net/neutron/+bug/1597913

Regarding API test coverage and support for sorting/pagination, following 
changes are on stage:

-  Document sorting/pagination extension existence: 
https://review.openstack.org/330058/

-  Added API extensions to detect sorting/pagination features 
https://review.openstack.org/329474/

-  Enable sorting and pagination by default: 
https://review.openstack.org/329481/

-  https://review.openstack.org/330482/
Please review the above patches.


2.   Grenade multinode gate status

a.   Experimental job for LinuxBridge: https://review.openstack.org/336793

b.  Make gate-grenade-dsvm-neutron-dvr-multinode voting: 
https://review.openstack.org/#/c/336116






===



Team info:

Upgrades Subteam has the weekly meetings on Mondays, 3PM UTC, wiki page: 
https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam



New patches are generally tracked under the following topic: 
https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db

Cheers,
Artur




















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

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

[Emilien Macchi]

Hi,

If you have any topic for our weekly meeting, please add it here:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160712

Like usual, we'll do the meeting only if we have something to discuss.

On Tue, Jul 5, 2016 at 10:56 AM, Emilien Macchi  wrote:
> No topic this week, meeting cancelled.
>
> See you next week!
>
> On Mon, Jul 4, 2016 at 4:34 PM, Emilien Macchi  wrote:
>> If you have any topic for our weekly meeting tomorrow, please add it here:
>> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160705
>>
>> If no topic, we will postpone the meeting to next week.
>> Thanks,
>>
>> On Tue, Jun 28, 2016 at 11:06 AM, Emilien Macchi  wrote:
>>> Meeting cancelled again, no topic this week.
>>> See you next week!
>>>
>>> On Mon, Jun 27, 2016 at 8:39 AM, Emilien Macchi  wrote:
 Hi,

 If you have any topic for our meeting tomorrow, please add them on the 
 etherpad:
 https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160628

 See you tomorrow,

 On Tue, Jun 21, 2016 at 10:59 AM, Emilien Macchi  
 wrote:
> Meeting cancelled, no topics this week.
>
> See you next week!
>
> On Mon, Jun 20, 2016 at 9:44 AM, Emilien Macchi  
> wrote:
>> Hi Puppeteers!
>>
>> We'll have our weekly meeting tomorrow at 3pm UTC on
>> #openstack-meeting-4.
>>
>> Here's a first agenda:
>> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160621
>>
>> Feel free to add more topics, and any outstanding bug and patch.
>>
>> See you tomorrow!
>> Thanks,
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



 --
 Emilien Macchi
>>>
>>>
>>>
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
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] [cross-project][infra][keystone] Moving towards a Identity v3-only on Devstack - Next Steps

[Raildo Mascena]

Hello Folks,

Following the feedback that we got on this email, during this last months
we implemented a couple of jobs to track this Identity v3-only behavior, so
you can find this jobs, on this links:

   - https://review.openstack.org/#/q/topic:v3-only-integrated
   -
   
https://review.openstack.org/#/q/status:merged+project:openstack-infra/project-config+branch:master+topic:v3-only-functionals-tests-gates

Besides that, we already fixed a lot of issues related to the keystoneauth
adoption and the session usage instead of v2 hardcoded authentication in
different services.

Finally, we updated the etherpad with the jobs issues related to v3-only
change on devstack, and we noticed that almost every issues was fixed and
the others already have at least a patch related to it.
https://etherpad.openstack.org/p/v3-only-devstack

So, as we discussed before, very early in the Otaca cycle is also the
timeframe we had discussed at summit so it looks like there is a good
consensus there, I believe we can get that proposal to TC.

Cheers,

Raildo


On Sun, May 15, 2016 at 9:03 PM Jamie Lennox  wrote:

> On 13 May 2016 at 04:15, Sean Dague  wrote:
>
>> On 05/12/2016 01:47 PM, Morgan Fainberg wrote:
>> > This  also comes back to the conversation at the summit. We need to
>> > propose the timeline to turn over for V3 (regardless of
>> > voting/non-voting today) so that it is possible to set the timeline that
>> > is expected for everything to get fixed (and where we are
>> > expecting/planning to stop reverting while focusing on fixing the
>> > v3-only changes).
>> >
>> > I am going to ask the Keystone team to set forth the timeline and commit
>> > to getting the pieces in order so that we can make v3-only voting rather
>> > than playing the propose/revert game we're currently doing. A proposed
>> > timeline and gameplan will only help at this point.
>>
>> A timeline would be good (proposed below), but there are also other bits
>> of the approach we should consider.
>>
>
> That was my job to get sent to the TC. I'll get on it.
>
>
>>
>> I would expect, for instance,
>> gate-tempest-dsvm-neutron-identity-v3-only-full to be on keystone, and
>> it does not appear to be. Is there a reason why?
>>
>
> To test that keystone works with keystone v3? Otherwise what you're doing
> is making it so that keystone's gate breaks every time neutron does
> something that's not v3 compatible which brings it to our attention but
> otherwise just gets in the way. The hope was to push the check job failure
> back to the service so that its not purely keystone's job to run around and
> fix all the other services when the incompatible change is discovered.
>
>
>>
>> With that on keystone, devstack-gate, devstack, tempest the integrated
>> space should be pretty well covered. There really is no need to also go
>> stick this on glance, nova, cinder, neutron, swift I don't think,
>> because they only really use keystone through pretty defined interfaces.
>>
>
> Initially i would have agreed, and there has been a voting job on devstack
> with keystone v3 only that proves that all of these services can work
> together for at least a cycle. Where we got stung was all the plugins and
> configuration options used in these services that don't get tested by that
> integrated gate job. The hope was that by pushing these jobs out to the
> services we would get more coverage of the service specific configurations
> - but I can see that might not be working.
>
>
>> Then some strategic use of nv jobs on things we know would have some
>> additional interactions here (because we know they are currently broken
>> or they do interesting things) like ironic, heat, trove, would probably
>> be pretty useful.
>>
>> That starts building up the list of known breaks the keystone folks are
>> tracking, which should get a drum beat every week in email about
>> outstanding issues, and issues fixed.
>>
>> The goal of gate-tempest-dsvm-neutron-identity-v3-only-full should not
>> be for that to be voting, ever. It should be to use that as a good
>> indicator that changing the default in devstack (and thus in the
>> majority of upstream jobs) to not ever enable v2.
>>
>> Because of how v3 support exists in projects (largely hidden behind
>> keystoneauth), it is really unlikely to rando regress once fixed. There
>> just aren't that many knobs a project has that would make that happen.
>> So I think we can make forward progress without a voting backstop until
>> we get to a point where we can just throw the big red switch (with
>> warning) on a Monday (probably early in the Otaca cycle) and say there
>> you go. It's now the project job to handle it. And they'll all get fair
>> warning for the month prior to the big red switch.
>>
>
> I agree. Very early in the Otaca cycle is also the timeframe we had
> discussed at summit so it looks like there is a good consensus there and
> i'll get that proposal to TC this week.
>
> For now we 

[openstack-dev] [Nova] Quick poll for live migration meeting this week

[Murray, Paul (HP Cloud)]

Hi All,

I think we can skip the live migration meeting this week unless anyone has 
something specific to discuss. Next week is the mid cycle, so I suggest the 
next meeting should be Tuesday 26th July.

Please let me know if you agree or disagree. Unless I hear otherwise I will 
assume its ok to kick off again after the mid cycle.

Regards,
Paul
__
OpenStack Development Mailing List (not for 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-docker] Retiring nova-docker project

[Davanum Srinivas]

Álvaro,

There is no plan for any other Nova driver that will drive a Docker
Daemon that i know.

Thanks,
Dims

On Mon, Jul 11, 2016 at 8:10 AM, Álvaro López García
 wrote:
> On 08 Jul 2016 (10:07), Davanum Srinivas wrote:
>> Tim,
>
> Hi Davanum,
>
>> I've initiated conversation a couple of times more than a year ago.
>>
>> http://lists.openstack.org/pipermail/openstack-operators/2015-May/thread.html#7129
>> http://lists.openstack.org/pipermail/openstack-operators/2015-May/thread.html#7006
>
> To be honest I overlooked and missed these emails in the operators
> mailing list. I am aware of several sites where it is being used so I
> would have reacted on these emails, sorry for that.
>
> What is the status and position of Zun (ex Higgings) with regards
> nova-docker? Will it support the same features in the (near) future?
> Does it make sense to maintain nova-docker until Zun fills the gap?
>
> Regards,
> --
> Álvaro López García  al...@ifca.unican.es
> Instituto de Física de Cantabria http://alvarolopez.github.io
> Ed. Juan Jordá, Campus UC  tel: (+34) 942 200 969
> Avda. de los Castros s/nskype: aloga.csic
> 39005 Santander (SPAIN)
>
> __
> OpenStack Development Mailing 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] [nova][nova-docker] Retiring nova-docker project

[Álvaro López García]

On 08 Jul 2016 (10:07), Davanum Srinivas wrote:
> Tim,

Hi Davanum,

> I've initiated conversation a couple of times more than a year ago.
> 
> http://lists.openstack.org/pipermail/openstack-operators/2015-May/thread.html#7129
> http://lists.openstack.org/pipermail/openstack-operators/2015-May/thread.html#7006

To be honest I overlooked and missed these emails in the operators
mailing list. I am aware of several sites where it is being used so I
would have reacted on these emails, sorry for that.

What is the status and position of Zun (ex Higgings) with regards
nova-docker? Will it support the same features in the (near) future?
Does it make sense to maintain nova-docker until Zun fills the gap?

Regards,
-- 
Álvaro López García  al...@ifca.unican.es
Instituto de Física de Cantabria http://alvarolopez.github.io
Ed. Juan Jordá, Campus UC  tel: (+34) 942 200 969
Avda. de los Castros s/nskype: aloga.csic
39005 Santander (SPAIN)

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

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Joshua Hesketh]

Hey Jesse,

Sorry for the delay. I've gone ahead and removed icehouse, juno and kilo
branches creating tags in their places.

Cheers,
Josh

On Wed, Jul 6, 2016 at 3:27 AM, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> From: Joshua Hesketh 
>
>
> I assume you want to wait for the tag to merge before removing the branch?
>
> The only tag job I can see for openstack-ansible* projects is the
> releasenotes one. This should be harmless as it just generates the notes
> for mitaka and liberty branches. I'm going to hold off until the final tag
> has merged anyway if you want to confirm this first.
>
>
> Thanks Josh – The final Kilo tag has merged so we’re good to go. We’re
> happy to also go straight ahead with the eol tags for the icehouse and juno
> branches too.
>
> --
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Alex Xu]

This propose is about using ResourceProviderTags as a solution to manage
Capabilities (Qualitative) in ResourceProvider.
The ResourceProviderTags is to describe the capabilities which are defined
by OpenStack Service (Compute Service,
Storage Service, Network Service etc.) and by users. The ResourceProvider
provide resource exposed by a single
compute node, some shared resource pool or an external resource-providing
service of some sort.  As such,
ResourceProviderTags is also expected to describe the capabilities of
single ResourceProvider or the capabilities of
ResourcePool.

The ResourceProviderTags is similar with ServersTags [0] which is
implemented in the Nova. The only difference is
that the tags is attached to the ResourceProvider. The API endpoint will be
" /ResourceProvider/{uuid}/tags", and it
will follow the API-WG guideline about Tags [1].

As the Tags are just strings, the meaning of Tag isn't defined by
Scheduler. The meaning of Tag is defined by
OpenStack services or Users. The ResourceProviderTags will only be used for
scheduling with a ResourceProviderTags
filter.

The ResourceProviderTags is very easy to cover the cases of single
ResourceProvider, ResourcePool and
DynamicResouces. Let see those cases one by one.

For single ResourceProvider case, just see how Nova report ComputeNode's
Capabilities. Firstly,  Nova is expected
to define a standard way to describe the Capabilities which provided by
Hypervisor or Hardware. Then those description
of Capabilities can be used across the Openstack deployment. So Nova will
define a set of Tags. Those Tags should
be included with prefix to indicated that this is coming from Nova. Also
the naming rule of prefix can be used to catalog
the Capabilities. For example, the capabilities can be defined as:

COMPUTE_HW_CAP_CPU_AVX
COMPUTE_HW_CAP_CPU_SSE

COMPUTE_HV_CAP_LIVE_MIGRATION
COMPUTE_HV_CAP_LIVE_SNAPSHOT


( The COMPUTE means this is coming from Nova. HW means this is hardware
related Capabilities. HV means this is
 capabilities of Hypervisor. But the catalog of Capabilities can be
discussed separated. This propose focus on the
 ResourceTags. We also have another idea about not using 'PREFIX' to manage
the Tags. We can add attributes to the
 Tags. Then we have more control on the Tags. This will describe separately
in the bottom. )

Nova will create ResourceProvider for the compute node, and report the
quantitative stuff, and report capabilities
by adding those defined tags to the ResourceProvider at same time. Then
those Capabilities are exposed by Nova
automatically.

The capabilities of ComputeNode can be queried through the API "GET
/ResourceProviders/{uuid}/tags".

For the ResourcePool case, let us use Shared Storage Pool as example. The
different Storage Pool may have
different capabilities. Maybe one of Pool are using SSD. For expose that
Capability, admin user can do as below:

1. Define the aggregates
  $AGG_UUID=`openstack aggregate create r1rck0610`

2. Create resource pool for shared storage
  $RP_UUID=`openstack resource-provider create "/mnt/nfs/row1racks0610/" \
--aggregate-uuid=$AGG_UUID`

3. Update the capacity of shared storage
  openstack resource-provider set inventory $RP_UUID \
--resource-class=DISK_GB \
--total=10 --reserved=1000 \
--min-unit=50 --max-unit=1 --step-size=10 \
--allocation-ratio=1.0

4. Add the Capabilities of shared storage
  openstack resource-provider add tags $RP_UUID --tag STORAGE_WITH_SSD

In this case, 'STORAGE_WITH_SSD' is defined by Admin user. This is the same
with Quantitative, where there
isn't agent to report the Quantitative, neither the Qualitative.

This is also easy to cover the DynamicResource case. Thinking of Ironic,
admin will create ResourcePool for
same hardware configuration bare-metal machines. Those machines will have
the same set of capabilities. So
those capabilities will be added to the ResourcePool as tags, this is
pretty same with SharedStoragePool case.

To expose cloud capabilities to users,  there is one more API endpoint 'GET
/ResourceProviders/Tags'. User can
get all the tags. Then user can know what kind of Capabilities the cloud
provides. The query parameter
will allow user to filter the Tags by the prefix rules.

This propose is intended to be a solution of managing Capabilities in the
scheduler with ResourceProvider. But yes,
look at how Nova implement the manage of Capabilities, this is just part of
solution. The whole solution still needs needs
other propose (like [2]) to describe how to model capabilities inside the
compute node and propose (like [3]) to
describe how to request capabilities.

Manage Tags with attributes
=
As described above, we add prefix to Tags to mark which service this Tag is
coming from and which catalog or
namespaces of Capabilities this Tags belongs to. An alternative idea is
adding attributes to the Tags.
We can use one attribute tags to mark the origin of 

Re: [openstack-dev] [Zun][Higgins] Request initial feedback for the design spec

[Yanyan Hu]

Hi, Hongbin, thanks a lot for initialize the spec, will check and leave
comments there.

2016-07-09 3:08 GMT+08:00 Hongbin Lu :

> Hi all,
>
>
>
> Because I cannot attend the team meeting next week, I would leave a
> message here: I am working on a spec to define the high-level design of the
> Zun service.
>
>
>
> https://etherpad.openstack.org/p/zun-containers-service-design-spec
>
>
>
> I would encourage everyone to participant on this efforts to sharp our
> project. Please feel free to edit or leave comments on the etherpad. Your
> feedback is greatly appreciated.
>
>
>
> Best regards,
>
> Hongbin
>
> __
> OpenStack Development Mailing 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,

Yanyan
__
OpenStack Development Mailing List (not for 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][SR-IOV][pci-passthrough] Reporting pci devices in hypervisor-show

[Daniel P. Berrange]

On Fri, Jul 08, 2016 at 03:45:10PM -0400, Jay Pipes wrote:
> On 07/08/2016 12:10 PM, Beliveau, Ludovic wrote:
> > I see a lot of values in having something like this for inventory
> > purposes and troubleshooting.
> > 
> > IMHO the information should be provided in two ways.
> > 
> > 1. Show PCI pools status per compute.  Currently the pools only have
> > information about how many devices are allocated in a pool ("count").
> > We should also derive from the pci_devices db table the number of PCI
> > devices that are available per pool (not just the number of allocated).
> > This information could be included in the hypervisor-show (or a new REST
> > API if this is found to be too noisy).
> > 
> > 2. More detailed information about each individual PCI devices (like you
> > are suggesting: parent device relationships, etc.).  This could be in a
> > separate REST API call.
> > 
> > We could even think about a third option where we could be showing
> > global PCI pools information for a whole region.
> > 
> > For discussions purposes, here's what pci_stats for a compute looks like
> > today:
> > {"count": 1, "numa_node": 0, "vendor_id": "8086", "product_id": "10fb",
> > "tags": {"dev_type": "type-PF", "physical_network": "default"}},
> > "nova_object.namespace": "nova"}
> > {"count": 3, "numa_node": 0, "vendor_id": "8086", "product_id": "10ed",
> > "tags": {"dev_type": "type-VF", "physical_network": "default"}},
> > "nova_object.namespace": "nova"}]}, "nova_object.namespace": "nova"}
> > 
> > Is there an intention to write a blueprint for this feature ?  If there
> > are interests, I don't mind working on it.
> 
> Personally, I hate the PCI device pool code and the whole concept of storing
> this aggregate "pool" information in the database (where it can easily
> become out of sync with the underlying PCI device records).

Yep, I really think we should avoid exposing this concept in our API,
at all costs. Aside from the issue you mentiohn, there's a second
issue that our PCI device code is almost certainly going to have to
be generalized in to host device code, since in order to support
TPMs, vGPUs and FPGAs, we're going to need to start tracking many
host devices which are not PCI. We should bear this in mind when
considered any public API exposure of PCI devices, as we don't want
to add an API that is immediately broken by need to add non-PCI
devices


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

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

Re: [openstack-dev] [keystone] Can anyone share some experience for how to configure keystone work with https

[Kseniya Tychkova]

Hi,
just follow instruction for your web server. For example, for Apache  -
https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
In short:
- create certificates
- install and enable ssl module
- enable ssl for keystone site (add directives in your
/etc/apache2/sites-available/keystone-wsgi. conf file)

On Mon, Jul 11, 2016 at 6:22 AM, Jay Lau  wrote:

> Hi,
>
> Does anyone have some experience or some document for how to configure
> keystone work with https? If so, can you please help share with me or show
> some links that can help?
>
> --
> Thanks,
>
> Jay Lau (Guangya Liu)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][Plugins] Please update your Fuel plugin's entries in DriverLog

[Irina Povolotskaya]

Hi to everyone,

please make sure your Fuel Plugin information in DriverLog [1] is
up-to-date, specifically:
- compatible OpenStack releases
- CI/CD
- maintainers list and their contact information.

Detailed instructions on working with DriverLog are found here [2].

Thank you.


[1] http://stackalytics.com/report/driverlog?project_id=openstack/fuel
[2]
https://wiki.openstack.org/wiki/DriverLog#How_To:_Add_a_new_Fuel_Plugin_to_DriverLog


-- 
Best regards,

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

Re: [openstack-dev] [Oslo] [ALL] Disable option value interpolation in oslo.config

[ChangBo Guo]

Does your project use option value interpolation ? As I know, nova use it.
we also disccussed in oslo team, should we deprecate this feature ?
Any thoughts ?

2016-07-08 22:14 GMT+08:00 ChangBo Guo :

> Hi ALL,
>
> I have been working a bug [1] about option value interpolation in
> oslo.config[2], in short, option value interpolation can't handle password
> containing special characters from environment variable and I  proposed a
> fix of provide way to forbid option value interpolation explicitly[3].
>
> copy of Doug Hellmann's coments:
>
> "The problem is that the end user who is setting the value of the option
> cannot control whether the option will do interpolation or not. So the
> programmer who defines the option has to make that choice, and then we
> can't change it because that would break existing deployments. The result
> is that end users won't know for any given option whether interpolation
> works or not, and if not why (did they do something wrong, or is it not
> supported).
>
> I've set -2 on this patch because I think it's a bad approach. I see 2
> other ways we could solve the problem you describe (and I agree that it's
> an issue we should help with).
>
> 1. We could have an option that turns off interpolation globally, and let
> the user control that by setting the flag in their configuration file. I'm
> not sure I like this, but it does give you what you're looking for at the
> risk of breaking applications that are relying on interpolation, like the
> nova example.
>
> 2. We could disable interpolation when we get values from environment
> variables. That would be a big behavioral change, so we would need to think
> about how to roll it out carefully. For example, do we provide a helper
> function to give to application developers who are setting default values
> to environment variables so the variable value can be escaped to avoid
> interpolation? Or do we build it into the Opt class somehow? I think I like
> the helper function approach but we should give it more thought."
> I would like to collect more suggestions to decide the direction to fix
> similar bug. Any thoughts ?
>
> [1]https://bugs.launchpad.net/oslo.config/+bug/1577731
> [2]
> http://docs.openstack.org/developer/oslo.config/cfg.html#option-value-interpolation
> [3]https://review.openstack.org/#/c/338668/
>
>
> --
> ChangBo Guo(gcb)
>



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

[openstack-dev] [mistral] Team meeting - 07/11/2016

[Renat Akhmerov]

Hi,

This is a reminder that we’ll have a team meeting today at #openstack-meeting 
at 16.00 UTC.


Agenda:

Review action items
Current status (progress, issues, roadblocks, further plans)
Custom Actions API
Name of the subproject with Actions API?
OK to use mistral-extra to store OpenStack actions? What changes do we need in 
its structure?
Open discussion

Feel free to bring your topics.

Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [ironic] Tooling for recovering nodes

[Tan, Lin]

Hi Jay, Dmitry and guys

I submit two patches to try recover nodes which stuck in deploying state:

1. fix the issue of the ironic-conductor was brought up with a different 
hostname.
 https://review.openstack.org/325026
2. clear the lock of nodes in maintenance states
 https://review.openstack.org/#/c/324269/

If above solutions are promising, then we don't need a new tool to recover 
nodes in deploying state.

B.R

Tan



-Original Message-
From: Jay Faulkner [mailto:j...@jvf.cc] 
Sent: Thursday, June 2, 2016 7:45 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [ironic] Tooling for recovering nodes

Some comments inline.


On 5/31/16 12:26 PM, Devananda van der Veen wrote:
> On 05/31/2016 01:35 AM, Dmitry Tantsur wrote:
>> On 05/31/2016 10:25 AM, Tan, Lin wrote:
>>> Hi,
>>>
>>> Recently, I am working on a spec[1] in order to recover nodes which 
>>> get stuck in deploying state, so I really expect some feedback from you 
>>> guys.
>>>
>>> Ironic nodes can be stuck in
>>> deploying/deploywait/cleaning/cleanwait/inspecting/deleting if the 
>>> node is reserved by a dead conductor (the exclusive lock was not released).
>>> Any further requests will be denied by ironic because it thinks the 
>>> node resource is under control of another conductor.
>>>
>>> To be more clear, let's narrow the scope and focus on the deploying 
>>> state first. Currently, people do have several choices to clear the 
>>> reserved lock:
>>> 1. restart the dead conductor
>>> 2. wait up to 2 or 3 minutes and _check_deploying_states() will clear the 
>>> lock.
>>> 3. The operator touches the DB to manually recover these nodes.
>>>
>>> Option two looks very promising but there are some weakness:
>>> 2.1 It won't work if the dead conductor was renamed or deleted.
>>> 2.2 It won't work if the node's specific driver was not enabled on 
>>> live conductors.
>>> 2.3 It won't work if the node is in maintenance. (only a corner case).
>> We can and should fix all three cases.
> 2.1 and 2.2 appear to be a bug in the behavior of _check_deploying_status().
>
> The method claims to do exactly what you suggest in 2.1 and 2.2 -- it 
> gathers a list of Nodes reserved by *any* offline conductor and tries to 
> release the lock.
> However, it will always fail to update them, because 
> objects.Node.release() raises a NodeLocked exception when called on a Node 
> locked by a different conductor.
>
> Here's the relevant code path:
>
> ironic/conductor/manager.py:
> 1259 def _check_deploying_status(self, context):
> ...
> 1269 offline_conductors = self.dbapi.get_offline_conductors()
> ...
> 1273 node_iter = self.iter_nodes(
> 1274 fields=['id', 'reservation'],
> 1275 filters={'provision_state': states.DEPLOYING,
> 1276  'maintenance': False,
> 1277  'reserved_by_any_of': offline_conductors})
> ...
> 1281 for node_uuid, driver, node_id, conductor_hostname in node_iter:
> 1285 try:
> 1286 objects.Node.release(context, conductor_hostname, 
> node_id)
> ...
> 1292 except exception.NodeLocked:
> 1293 LOG.warning(...)
> 1297 continue
>
>
> As far as 2.3, I think we should change the query string at the start 
> of this method so that it includes nodes in maintenance mode. I think 
> it's both safe and reasonable (and, frankly, what an operator will 
> expect) that a node which is in maintenance mode, and in DEPLOYING 
> state, whose conductor is offline, should have that reservation cleared and 
> be set to DEPLOYFAILED state.

This is an excellent idea -- and I'm going to extend it further. If I have any 
nodes in a *ING state, and they are put into maintenance, it should force a 
failure. This is potentially a more API-friendly way of cleaning up nodes in 
bad states -- an operator would need to maintenance the node, and once it 
enters the *FAIL state, troubleshoot why it failed, unmaintenance, and return 
to production.

I obviously strongly desire an "override command" as an operator, but I really 
think this could handle a large percentage of the use cases that made me desire 
it in the first place.

> --devananda
>
>>> Definitely we should improve the option 2, but there are could be 
>>> more issues I didn't know in a more complicated environment.
>>> So my question is do we still need a new command to recover these 
>>> node easier without accessing DB, like this PoC [2]:
>>>ironic-noderecover --node_uuids=UUID1,UUID2 
>>> --config-file=/etc/ironic/ironic.conf
>> I'm -1 to anything silently removing the lock until I see a clear use 
>> case which is impossible to improve within Ironic itself. Such utility may 
>> and will be abused.
>>
>> I'm fine with anything that does not forcibly remove the lock by default.
I agree such a utility could be abused. I don't think that's a good argument 
for not writing it for operators. However, I agree that any