Re: [openstack-dev] [requirements][packaging] Normalizing requirements file

[Haïkel]

2016-06-22 7:23 GMT+02:00 Tony Breeds :
>
> I'm fine with doign something like this.  I wrote [1] some time ago but didn't
> push on it as I needed to verify that this wouldn't create a "storm" of
> pointless updates that just reorder things in every projects 
> *requirements.txt.
>
> I think the first step is to get the 'tool' added to the requirements repo to
> make it easy to run again when things get out of wack.
>
> perhaps openstack_requirements/cmds/normalize ?
>

Thanks Swapnil and Tony for your positive comments.

I didn't submit the script as I wanted to see in real conditions, how
well it fare and
get feedback from my peers, first. I'll submit the script in a separate review.

> we can bikeshed on the output format / incrementally improve things if we have
> a common base.
>

makes sense, I tried to stay as close to the main current style

Regards,
H.

> So I think that's a -1 on your review as it stands until we have the tool 
> merged.
>
> Yours Tony.
>
> [1] https://gist.github.com/tbreeds/f250b964383922bdea4645740ae4b195
>

__
OpenStack Development Mailing List (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] [mistal] Mistral logo ideas?

[Renat Akhmerov]

Hi,

We’d like to finally come up with a logo for Mistral and it’d be cool to hear 
some ideas from the community.

Some ideas from me:
• A picture of a graph (but the point is that it must be very very 
simple)
• A picture of a rocket (meaning that Mistral helps take off of the 
ground)
• A picture of a conductor (meaning that Mistral orchestrates things)
• A picture of a fast train
• A picture of a puzzle (meaning that Mistral helps gluing things)
• Something related with wind (like Mistral wind)


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] [oslo][monasca][requirements] Kafka 1.x for Oslo.Messaging and Monasca

[Keen, Joe]

Davanum,
  We started work on getting Monasca into the global requirements with two
reviews [1] [2] that add gate jobs and check requirements jobs for the
Monasca repositories.  Some repositories are being adapted to use versions
of libraries that OpenStack currently accepts [3] and we¹re looking at the
libraries we use that are not currently part of OpenStack and seeing if
they¹re worth trying to add to the global requirements.  We¹re hoping to
be able to start adding the global requirements reviews within a week or
two.

We definitely want to talk with the oslo.messaging team and explain the
ways we use Kafka and what effects the move to the 1.x versions of the
library has on us.  I¹ve attempted to contact the oslo.messaging team in
the oslo IRC channel to see if we can talk about this at a weekly meeting
but I wasn¹t able to connect with anyone.  Would you prefer that
conversation happen on the mailing list here or could we add that topic to
the next weekly meeting?

[1] https://review.openstack.org/#/c/316293/
[2] https://review.openstack.org/#/c/323567/
[3] https://review.openstack.org/#/c/323598/

On 6/21/16, 6:53 AM, "Davanum Srinivas"  wrote:

>Roland Hochmuth, Joe Keen,
>
>The oslo.messaging folks have been trying off and on again [1] to get
>to python-kafka 1.x. Right now they are waiting on the Monasca team as
>we reverted python-kafka 1.x in [2] for the Monasca Team.
>
>I still don't see a review for adding Monasca to projects.txt which is
>concerning. Is there work being done to get to that point?
>
>The oslo.messaging team will file a review to update to 1.x again when
>they are ready, when that happens, we will end up breaking Monasca CI
>jobs again. Unless of course Monasca is in projects.txt by that time
>and adhering to requirements.
>
>If both oslo.messaging and Monasca are under requirements, we still
>need a way to move forward together. So please treat this email thread
>as an opportunity to talk to each other :) Which should have started
>ideally when we did [2]
>
>Thanks,
>Dims
>
>[1] 
>https://review.openstack.org/#/q/kafka+project:openstack/oslo.messaging+NO
>T+is:merged+NOT+is:abandoned
>[2] https://review.openstack.org/#/c/316259/
>
>-- 
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [requirements][packaging] Normalizing requirements file

[Tony Breeds]

On Wed, Jun 22, 2016 at 06:45:31AM +0200, Haïkel wrote:
> Hi,
> 
> as a packager, I spend a lot of time to scrutinize the requirements
> repo, and I find it easier to read if specifiers are ordered.
> So in a quick glance, you can check which is the min version required
> and max one without trying to search them among other specifiers.
> I scripted a basic linter to do that (which also normalize comments to
> PEP8 standards)
> 
> Initial review is here:
> https://review.openstack.org/#/c/332623/
> 
> script is available here;
> https://gist.github.com/hguemar/7a17bf93f6c8bd8ae5ec34bf9ab311a1
> 
> Your thoughts?

I'm fine with doign something like this.  I wrote [1] some time ago but didn't
push on it as I needed to verify that this wouldn't create a "storm" of
pointless updates that just reorder things in every projects *requirements.txt.

I think the first step is to get the 'tool' added to the requirements repo to
make it easy to run again when things get out of wack.

perhaps openstack_requirements/cmds/normalize ?

we can bikeshed on the output format / incrementally improve things if we have
a common base.

So I think that's a -1 on your review as it stands until we have the tool 
merged.

Yours Tony.

[1] https://gist.github.com/tbreeds/f250b964383922bdea4645740ae4b195


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

Re: [openstack-dev] [requirements][packaging] Normalizing requirements file

[Swapnil Kulkarni (coolsvap)]

On Wed, Jun 22, 2016 at 10:15 AM, Haïkel  wrote:
> Hi,
>
> as a packager, I spend a lot of time to scrutinize the requirements
> repo, and I find it easier to read if specifiers are ordered.
> So in a quick glance, you can check which is the min version required
> and max one without trying to search them among other specifiers.
> I scripted a basic linter to do that (which also normalize comments to
> PEP8 standards)
>
> Initial review is here:
> https://review.openstack.org/#/c/332623/
>
> script is available here;
> https://gist.github.com/hguemar/7a17bf93f6c8bd8ae5ec34bf9ab311a1
>
> Your thoughts?
>
> Regards,
> H.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Haikel,

This looks good and the global-requirements.txt now looks much cleaner.

Can you add the linter to the tools directory in requirements. We can
use it in our gates.

Swapnil

__
OpenStack Development Mailing List (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] [requirements][packaging] Normalizing requirements file

[Haïkel]

Hi,

as a packager, I spend a lot of time to scrutinize the requirements
repo, and I find it easier to read if specifiers are ordered.
So in a quick glance, you can check which is the min version required
and max one without trying to search them among other specifiers.
I scripted a basic linter to do that (which also normalize comments to
PEP8 standards)

Initial review is here:
https://review.openstack.org/#/c/332623/

script is available here;
https://gist.github.com/hguemar/7a17bf93f6c8bd8ae5ec34bf9ab311a1

Your thoughts?

Regards,
H.

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

Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

[Angus Lees]

On Wed, 22 Jun 2016 at 05:59 Matt Riedemann 
wrote:

> Angus, what should we be looking at from the privsep side for debugging
> this?
>

The line above the screen-n-cpu.txt.gz failure you linked to is:
2016-06-21 16:21:30.994

1840 WARNING oslo.privsep.daemon [-] privsep log:
/usr/local/bin/nova-rootwrap: Unauthorized command: privsep-helper
--config-file /etc/nova/nova.conf --privsep_context
os_brick.privileged.default --privsep_sock_path /tmp/tmpV5w2VC/privsep.sock
(no filter matched)

 .. so nova-rootwrap is rejecting the privsep-helper command line because
no filter matched.  This indicates the nova compute.filters file has not
been updated, or is incorrect.


As was later pointed out by mtreinish, grenade is attempting to run the
newton code against mitaka configs, and this includes using mitaka rootwrap
filters.   Unfortunately, the change to add privsep to nova's rootwrap
filters wasn't approved until the newton cycle (so that all the os-brick
privsep-related changes could be approved together), and so this doesn't
Just Work.

Digging in further, it appears that there *is* a mechanism in grenade to
upgrade rootwrap filters between major releases, but this needs to be
explicitly updated for each project+release and hasn't been for
nova+mitaka->newton.  I'm not sure how this is *meant* to work, since the
grenade "theory of upgrade" doesn't mention when configs should be updated
- the only mechanism provided is an "exception ... used sparingly."

Anyway, I added an upgrade step for nova mitaka->newton that updates
rootwrap filters appropriately(*).  Again, I'm not sure what this
communicates to deployers compared to cinder (which *did* have the updated
rootwrap filter merged in mitaka, but of course that update still needs to
be installed at some point).
(*) https://review.openstack.org/#/c/332610

 - Gus
__
OpenStack Development Mailing List (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] Reply: Release naming for P and Q open for nominations

[Lizhonghua (C)]

2016-6-22 4:50 Monty Taylor [mailto:mord...@inaugust.com] wrote:
> Hey everyone!
> 
> It's time to pick a name for the P and Q releases.
> 
> If you have a name you'd like us to vote on, please add it here:
> 
> https://wiki.openstack.org/wiki/Release_Naming/P_Proposals
> 
> https://wiki.openstack.org/wiki/Release_Naming/Q_Proposals
> 
> The nominations will be open until 2016-06-28 23:59:59 UTC.
> 
> If you don't remember the rules, they're here:
> 
> http://governance.openstack.org/reference/release-naming.html
> 
> Names which do not meet these criteria but otherwise sound really cool should 
> be added to a separate section of the wiki page and the TC may make an 
> exception for one or more of them to be considered in the Condorcet poll. The 
> naming official is responsible for presenting the list of exceptional names 
> for consideration to the TC before the poll opens.

I propose "Panda"[1] as a nominated name of P.
though it doesn't meet the criteria, I think it is a cool word, may it be made 
an exception?

[1] https://en.wikipedia.org/wiki/Giant_panda 
__
OpenStack Development Mailing List (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] RHEL free for developer use (was: Require a level playing field for OpenStack projects)

[Jeremy Stanley]

On 2016-06-21 14:48:58 +0200 (+0200), Zane Bitter wrote:
> That isn't my understanding, but it's hard to give a definitive
> answer without knowing what kinds of non-free software you're
> referring to (since I know there have been fierce disagreements
> even e.g. within Debian on topics like firmware blobs).
[...]

While I do tend to ascribe to the Debian and OpenBSD (and sometimes
FSF) concepts of "free," I'm mostly referring to source
redistribution issues I experienced in bygone years (my last direct
experiences were back in the RHN/up2date days). Particularly things
like, if I want to (re)build RPMs for RHEL where do I find the SRPMs
used to create them and what license are they distributed under (at
least back then you needed portal access/entitlements to even be
able to download the source packages)?

Poking around a bit, it looks they've since started maintaining
specfiles in public source code repositories and with RHEL 7 they've
made some commitment to keeping CentOS 7 SRPMs consistent (in line
with the community merger) so you can download those directly even
if you aren't a customer and want "RHEL equivalent" SRPMs. I think
it's laudable that Red Hat has started to treat things like
packaging metadata as part of their software and consider it freely
redistributable now, though it makes me wonder if RHEL AS 7 and
CentOS 7 are supposed to be fundamentally the same at this point
(minus support contracts) then what is the point of making RHEL free
for developer use (does it come with a free support contract)? And
if the difference is that there's software/features available in
RHEL that you can't get under CentOS, it sounds an awful lot like an
"open core" scenario still.
-- 
Jeremy Stanley

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

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting today. The meeting is being held Wednesday
UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

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

Please feel free to add items to the agenda.

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

Re: [openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

[Fox, Kevin M]

Worse, if you use ironic, I think configdrive is mapped to a partition at 
provision time. so hot plugging can't ever work in that scenario.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Tuesday, June 21, 2016 4:15 PM
To: openstack-dev
Subject: Re: [openstack-dev] [nova] ability to set metadata on instances
(but config drive is not updated)

Excerpts from Joshua Harlow's message of 2016-06-21 15:12:09 -0700:
> Agreed, it appears supported right-now (whether intentional or not),
>
> So the question at that point is what can we do to make it better...
>
> I think we all agree that the config-drive probably shouldn't have the
> equivalent of the metadata service in it; because if the metadata
> service can change over time, and the config-drive can't then it's a bad
> equivalent and that should be rectified, either by making it an
> equivalent or making it be accepted that it is not, and ideally trimming
> the data in it to not confuse people (ie by providing static networking
> configuration only, and leaving the items that can be dynamic to the
> dynamic metadata service).
>
> Of course this whole mess IMHO gets into, 'why don't we just have an
> agreed up agent that can be used'; because that's what the metadata
> service is starting to become (a crappy version of an agent); but I digress.
>

Not sure I agree with your initial stipulation. It shouldn't be a
surprise, at all, to any user, that an HTTP service is updated live,
while an ISO attached to an instance is kept static.

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

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

Re: [openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

[Dan Smith]

> I'm going to have to agree with Jay - and I believe with something Clint
> said earlier.
> 
> Use metadata/config-drive to bootstrap you. Then use your actual tools
> (puppet/chef/ansible/salt/juju/cfengine) to interact with the node once
> it's enrolled in whatever you use to orchestrate cloud things. The best
> part about doing that is that your orchestration layer can talk to the
> OpenStack APIs AND to your nodes. Most of them also support key-value
> pairs, as well as updating them.

Yep, agree as well. I hate that metadata is changeable, but I'm not sure
there is much we can do about it now because I think at least one
"feature" is implemented this way. However, definitely +1 to not adding
any more such pain.

We've seen plenty of issues around scaling (read: puppet DoSing) the
metadata stuff. Caching it forever as a static file and/or using
configdrive makes those operations so much more efficient, especially in
the face of dumb things like facter constantly banging the crap out of it.

Many people ask us to reimplement things like auth, nagios, and config
management in nova. That doesn't mean it's something we should do.

--Dan

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

Re: [openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

[Clint Byrum]

Excerpts from Joshua Harlow's message of 2016-06-21 15:12:09 -0700:
> Agreed, it appears supported right-now (whether intentional or not),
> 
> So the question at that point is what can we do to make it better...
> 
> I think we all agree that the config-drive probably shouldn't have the 
> equivalent of the metadata service in it; because if the metadata 
> service can change over time, and the config-drive can't then it's a bad 
> equivalent and that should be rectified, either by making it an 
> equivalent or making it be accepted that it is not, and ideally trimming 
> the data in it to not confuse people (ie by providing static networking 
> configuration only, and leaving the items that can be dynamic to the 
> dynamic metadata service).
> 
> Of course this whole mess IMHO gets into, 'why don't we just have an 
> agreed up agent that can be used'; because that's what the metadata 
> service is starting to become (a crappy version of an agent); but I digress.
> 

Not sure I agree with your initial stipulation. It shouldn't be a
surprise, at all, to any user, that an HTTP service is updated live,
while an ISO attached to an instance is kept static.

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

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Chris Hoge]

> On Jun 20, 2016, at 6:56 AM, Doug Hellmann  wrote:
> 

> 
> I'm also, I think, edging away from the "we need to find a compromise"
> camp into the "why is this turning into such a big deal" camp. How did
> we get into a situation where the community has set a clear direction,
> the trademark certification system has a long lead time built in, and
> vendors are still not able to maintain certification?

If I had to make an educated guess, it’s because product managers
have to produce a roadmap with goals and features that consider
both what’s happening upstream, what is currently deployed, and
existing customers.

Just pulling attributes that were once ‘ok’ within the ecosystem and
now aren’t (even with lead time) isn’t as easy as “just change the
response”. It takes time, and given the year-long cycle that DefCore
has adopted for re-testing and the relative youth of the OpenStack
Powered Trademark program, it’s not unsurprising that a few
clouds have been hit by this.

I’ve spoken with all three vendors who are being hit by this, and
two definitely have a longer lead time to work on this. The third
is using the extra responses internally and are currently working
on changing their custom tools to get the extra information in
a different way.

I’ve also spoken with another vendor who is going to be caught
by it, though, and have explained the situation to them and
they are considering their options.

I am now actively telling vendors who are still sending additional
properties to start with with the Nova team upstream to have
their additional properties micro-versioned.

> Are the systems
> running modified versions of newer OpenStack that can't be certified
> with older versions of Tempest?

With the volume of bug fixes, refactoring, and general improvements
from the last year, I’d say no.

-Chris

> 
> Doug

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

[openstack-dev] [Neutron][networking-sfc] NO networking-sfc project IRC meetings on 6/23/2016 and 6/30/2016

[Cathy Zhang]

Hi everyone,
Since some of the project members are either in Summit/Conference or on 
vacation, we will not have project meetings on 6/23/2016 and 6/30/2016.
Thanks,
Cathy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

[Joshua Harlow]

Agreed, it appears supported right-now (whether intentional or not),

So the question at that point is what can we do to make it better...

I think we all agree that the config-drive probably shouldn't have the 
equivalent of the metadata service in it; because if the metadata 
service can change over time, and the config-drive can't then it's a bad 
equivalent and that should be rectified, either by making it an 
equivalent or making it be accepted that it is not, and ideally trimming 
the data in it to not confuse people (ie by providing static networking 
configuration only, and leaving the items that can be dynamic to the 
dynamic metadata service).


Of course this whole mess IMHO gets into, 'why don't we just have an 
agreed up agent that can be used'; because that's what the metadata 
service is starting to become (a crappy version of an agent); but I digress.


Chris Friesen wrote:

On 06/19/2016 11:57 AM, Clint Byrum wrote:

Excerpts from Joshua Harlow's message of 2016-06-17 15:04:38 -0700:



Now if I am using the configdrive instead of the metadata server at that
special/magic ip that same metadata never seems to change (I assume the
configdrive would have to be 'ejected' and then a new configdrive
created and then that configdrive 'reinserted'); was anyone aware of a
bug that would solve this (it does appear to be a feature difference
that could/should? be solved)?



That's not a bug. AFAIK, it was never intended to be updated.





Why this is something useful (from my view) is that we (at godaddy) have
a cron job that polls that metadata periodically and it generates a
bunch of polling traffic (especially when each VM does this) and that
traffic could be removed if such a 'eject' and 'reinsert' happens
instead (since then the cron job could become a small program that
listens for devices being inserted/removed and does the needed actions
then, which is better than polling endlessly for data that hasn't
changed).


I think you're abusing Nova to do what your config management system
should be doing. The config drive and metadata service are not meant
to be continuously polled or updated, they're for bootstrapping into
a continuous config management system.


While this is true, it seems to be a commonly-requested item. I just had
a customer rep asking whether we support updating instance metadata for
a running instance, since apparently it's possible with AWS.

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 Development Mailing List (not for 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] ability to set metadata on instances (but config drive is not updated)

[Chris Friesen]

On 06/19/2016 11:57 AM, Clint Byrum wrote:

Excerpts from Joshua Harlow's message of 2016-06-17 15:04:38 -0700:



Now if I am using the configdrive instead of the metadata server at that
special/magic ip that same metadata never seems to change (I assume the
configdrive would have to be 'ejected' and then a new configdrive
created and then that configdrive 'reinserted'); was anyone aware of a
bug that would solve this (it does appear to be a feature difference
that could/should? be solved)?



That's not a bug. AFAIK, it was never intended to be updated.





Why this is something useful (from my view) is that we (at godaddy) have
a cron job that polls that metadata periodically and it generates a
bunch of polling traffic (especially when each VM does this) and that
traffic could be removed if such a 'eject' and 'reinsert' happens
instead (since then the cron job could become a small program that
listens for devices being inserted/removed and does the needed actions
then, which is better than polling endlessly for data that hasn't changed).


I think you're abusing Nova to do what your config management system
should be doing. The config drive and metadata service are not meant
to be continuously polled or updated, they're for bootstrapping into
a continuous config management system.


While this is true, it seems to be a commonly-requested item.  I just had a 
customer rep asking whether we support updating instance metadata for a running 
instance, since apparently it's possible with AWS.


Chris

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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Barrett, Carol L]

> On Jun 21, 2016, at 2:56 AM, Thierry Carrez  wrote:
> 
> Chris Dent wrote:
>> On Mon, 20 Jun 2016, Doug Wiegley wrote:
>>> On Jun 21, 2016, at 2:19 PM, Carol Barrett  
>>> wrote:
>>> So, it sounds like you've just described the job of the TC. And they 
>>> have so far refused to define OpenStack, leading to a series of 
>>> derivative decisions that seem ... inconsistent over time.
>> 
>> Thanks for writing down what I was thinking. I agree that OpenStack 
>> needs some architectural vision, direction, leadership, call it what 
>> you will. Every time I've voted for the _Technical_ Committee that 
>> leadership is what I've wanted my vote to be creating.
> 
> The TC is a representative body which is elected to make top-down decisions 
> on OpenStack. However, as much as our community loves the idea of "technical 
> leadership" and "vision", they hate the top-down decisions that come with it 
> (especially when that top-down decision doesn't go their way). They prefer 
> bottom-up consensus.
> 
> So I'd argue that you need both. You need the TC whenever a hard call has to 
> be made, but in order to minimize the number of those hard calls (and favor 
> consensus building) you also need working groups to build a bottom-up 
> reasonable way forward.

>>This reads very strange to me, as I'd expect a group of technical leaders to 
>>both make hard calls *and* to be able to build consensus on overall direction 
>>and vision. They're >>two sides of the same coin. What is it about our 
>>process that means the TC can't build consensus on direction, but can only 
>>impose its will? I expect you didn't mean it to >>sound that way, though. Is 
>>the workload too high on the bookkeeping to prevent the vision building? Are 
>>we too afraid of the implications of defining 'what is openstack?', >>and 
>>what it might mean to existing projects and the community? I'd think that in 
>>the long-run, it'd prevent seemingly unrelated topics from seeming to go 
>>sideways so >>often, and prevent a lot of these "hard calls".

+1. Making decisions is an element of being a leader. As a community, I believe 
we need this role filled.

>>But, I'm also on the fringe that is very ready to call the "big tent" a 
>>failed experiment in attempting to avoid hard calls, too.

> 
>> It may be that an architecture working group can provide some 
>> guidance that people will find useful. Against the odds I think those 
>> of us in the API-WG have actually managed to have a positive 
>> influence. We've not shaken things down to the foundations from which 
>> a great a glorious future may be born -- a lot of compromises have 
>> been made and not everybody wants to play along -- but things are 
>> going in the right direction, for some people, in some projects.
>> Maybe a similar thing can happen with architecture.
> 
> That is my hope. I see the API WG and the Architecture WG as groups of 
> experts in specific domains preparing recommendations and long-term plans. 
> They don't have authority to force them onto projects. Ideally projects adopt 
> them because they see them as the right way to do things.
> 
> And for the very few things that the TC deems necessary for OpenStack and 
> where bottom-up didn't get it in a specific project (if all else fails), the 
> TC can make a top-down request to a project to do things a certain way. The 
> project can them either comply or reject the TC oversight and become an 
> unofficial project.

>>Don't get me wrong, I welcome this initiative. I find it mildly disconcerting 
>>that the folks that I thought we were electing to fill this role will instead 
>>be filled by others, but the vacuum does need to be filled, and I thank Clint 
>>for stepping up.
+1. I appreciate Clint making this proposal. I think a cohesive, consistent 
architecture across OpenStack is crucial to our long term efficiency and 
sustaining a high rate of innovation.

Thanks,
Carol


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


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

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

[openstack-dev] Release naming for P and Q open for nominations

[Monty Taylor]

Hey everyone!

It's time to pick a name for the P and Q releases.

If you have a name you'd like us to vote on, please add it here:

https://wiki.openstack.org/wiki/Release_Naming/P_Proposals

https://wiki.openstack.org/wiki/Release_Naming/Q_Proposals

The nominations will be open until 2016-06-28 23:59:59 UTC.

If you don't remember the rules, they're here:

http://governance.openstack.org/reference/release-naming.html

But I'll paste in the text here:

The following rules are designed to provide some consistency in the
pattern used to select release names, provide a fun challenge in finding
names that meet the criteria, and prevent unwieldy names from being chosen.

  1  Each release name must start with the letter of the ISO basic Latin
alphabet following the initial letter of the previous release, starting
with the initial release of “Austin”. After “Z”, the next name should
start with “A” again.

  2  The name must be composed only of the 26 characters of the ISO
basic Latin alphabet. Names which can be transliterated into this
character set are also acceptable.

  3  The name must refer to the physical or human geography of the
region encompassing the location of the OpenStack design summit for the
corresponding release.

  4  The name must be a single word with a maximum of 10 characters.
Words that describe the feature should not be included, so “Foo City” or
“Foo Peak” would both be eligible as “Foo”.

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may
make an exception for one or more of them to be considered in the
Condorcet poll. The naming official is responsible for presenting the
list of exceptional names for consideration to the TC before the poll opens.

Monty

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

Re: [openstack-dev] [Tripleo] X509 Management

[Juan Antonio Osorio]

On Tue, Jun 21, 2016 at 10:51 PM, Adam Young  wrote:

> On 06/21/2016 02:42 PM, Juan Antonio Osorio wrote:
>
> Adam, this is pretty much the proposal for TLS for the internal services
> (which you were added already as a reviewer for the spec)
> https://review.openstack.org/#/c/282307/
> The services in the overcloud fetching their certificates via certmonger
> is actually work in progress, which you could review here:
> https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
> Only thing is that currently this approach assumes FreeIPA, so the nodes
> need to be registered beforehand (and then trigger self-enrollment via some
> hooks).
> Also, the spec that I'm pointing to doesn't require the CA to be the in
> undercloud and it could be another node. But hey, if we could deploy Anchor
> on the Undercloud, then that could be used, so we wouldn't need another
> node for this means.
>
>
>
> Yes, I was basing my proposal her around your work.  I want there to be
> something guaranteed for Certmonger to talk to, and I realize that Heat can
> probably play that role.
>
> Anchor might also be viable here, I just don't want to force it as a
> dependency.  We are talking the selfsigned use case here, so it should be
> minimal overhead.
>

 I think it's a better idea to have Anchor as a dependency than try to brew
CA functionality into Heat via os-*-config. Maybe a Heat person can answer
this? Then for more complex use-cases we can use FreeIPA. Do we have Anchor
packetized in RDO?

>
> Anyway, in each of the service's profiles (the puppet manifests) I'm
> setting up the tracking of the certificates with the certmonger's puppet
> manifest.
>
> BR
>
> On Tue, Jun 21, 2016 at 5:39 PM, Adam Young  wrote:
>
>> When deploying the overcloud with TLS, the current "no additional
>> technology" approach is to use opensssl and self signed.  While this works
>> for a Proof of concept, it does not make sense if the users need to access
>> the resources from remote systems.
>>
>> It seems to me that the undercloud, as the system of record for deploying
>> the overcloud, should be responsible for centralizing the signing of
>> certificates.
>>
>> When deploying a service, the puppet module sure trigger a getcert call,
>> which registers the cert with  Certmonger.  Certmonger is responsible for
>> making sure the CSR gets to the signing authority, and fetching the cert.
>>
>> Certmonger works via helper apps.  While there is currently a "self
>> signed" helper, this does not do much if two or more systems need to have
>> the same CA sign their certs.
>>
>> It would be fairly simple to write a certmonger helper program that sends
>> a CSR from a controller or compute node to the undercloud, has the Heat
>> instance on the undercloud validate the request, and then pass it on to the
>> signing application.
>>
>> I'm not really too clear on how callbacks are  done from the
>> os-collect-config processes to Heat, but I am guessing it is some form of
>> Rest API that could be reused for this work flow?
>>
>>
>> I would see this as the lowest level of deployment.  We can make use of
>> Anchor or Dogtag helper apps already.  This might also prove a decent
>> middleground for people that need an automated approach to tie in with a
>> third party CA, where they need some confirmation from the deployment
>> process that the data in the CSR is valid and should be signed.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@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
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@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] Gerrit downtime on 1 July 2016 at 20:00 UTC

[Elizabeth K. Joseph]

Hi everybody,

On 1 July 2016 at 20:00 UTC Gerrit will be unavailable for
approximately 120 minutes (2 hours) while we upgrade
zuul.openstack.org and static.openstack.org to Ubuntu Trusty.

During this time, running jobs will be stopped as both new servers for
zuul.openstack.org and static.openstack.org will be brought online.

If you have any questions about the maintenance, please reply here or
contact us in #openstack-infra on freenode.

-- 
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] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

"discuss"  wrote on 06/17/2016 05:24:19
PM:

> From: Cathy Zhang 
> To: Na Zhu 
> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)"  d...@lists.openstack.org>, John McDowall
> , discuss 
> Date: 06/17/2016 05:25 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" 
>
> Hi Juno,
>
> Here is an example.
>
> SrcSF   DST
> | |  |   |
> 1 2  3   4
> OVS1==OVS2==OVS3
>
> For bump-in-the-wire SF type, since what it does is just to pass the
> packet from its ingress port to egress port, broadcast and multicast
> packets will form  a loop on port 2 and 3.
> This problem is not specific to SFC though. A simple way to solve
> this is to put a bump-in-the-wire SF’s port 2 and port 3 in
> different subnets. For L3 SF, this is not an issue.

The above is a good reason for following OVN's pipeline logic
and not punting a packet to an output port in the ingress pipeline
(as I first expressed concerns about in [1]).

There is a loopback check in table 34 (between the ingress and egress
pipelines) that we can look at using to break the loops - program it
to drop broadcast/multicast traffic going between ports 2 and 3 and
the loop is broken.

Ryan

[1] http://openvswitch.org/pipermail/discuss/2016-May/021419.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

[Matt Riedemann]

On 6/15/2016 1:11 AM, Angus Lees wrote:

oslo.privsep change: https://review.openstack.org/#/c/329766/
And the nova change that uses it: https://review.openstack.org/#/c/329769

In particular I'm unsure if os-brick/os-vif is even loaded at this point
in nova-compute main().  Does anyone know when that actually happens or
shall I go exploring?

 - Gus



An update on this.

The oslo.privsep change is merged and released in 1.9.0.

The nova change was updated to depend on oslo.privsep>=1.9.0.

To test that fix with os-brick 1.4.0, I made this change to requirements:

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

That depends on the nova fix and enables os-brick 1.4.0 which is the 
version that uses oslo.privsep.


It also depends on a requirements change to stable/mitaka to enable 
os-brick 1.4.0. I wasn't sure if this was necessary though given 
upper-constraints for stable/mitaka already caps brick at 1.2.0.


Anyway, it still fails in the grenade multinode job even with the nova 
and privsep fixes:


http://logs.openstack.org/85/331885/2/check/gate-grenade-dsvm-multinode/415e1bc/logs/new/screen-n-cpu.txt.gz?level=TRACE#_2016-06-21_16_21_31_015

And I confirmed via pip-freeze that it's using oslo.privsep 1.9.0 and 
os-brick 1.4.0:


http://logs.openstack.org/85/331885/2/check/gate-grenade-dsvm-multinode/415e1bc/logs/pip2-freeze.txt.gz

I did verify that it's correctly pulling in the dependent nova fix:

http://logs.openstack.org/85/331885/2/check/gate-grenade-dsvm-multinode/415e1bc/logs/devstack-gate-setup-workspace-new.txt.gz#_2016-06-21_15_37_02_958

Angus, what should we be looking at from the privsep side for debugging 
this?


--

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] [Tripleo] X509 Management

[Adam Young]

On 06/21/2016 02:42 PM, Juan Antonio Osorio wrote:
Adam, this is pretty much the proposal for TLS for the internal 
services (which you were added already as a reviewer for the spec) 
https://review.openstack.org/#/c/282307/
The services in the overcloud fetching their certificates via 
certmonger is actually work in progress, which you could review here: 
https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
Only thing is that currently this approach assumes FreeIPA, so the 
nodes need to be registered beforehand (and then trigger 
self-enrollment via some hooks).
Also, the spec that I'm pointing to doesn't require the CA to be the 
in undercloud and it could be another node. But hey, if we could 
deploy Anchor on the Undercloud, then that could be used, so we 
wouldn't need another node for this means.



Yes, I was basing my proposal her around your work.  I want there to be 
something guaranteed for Certmonger to talk to, and I realize that Heat 
can probably play that role.


Anchor might also be viable here, I just don't want to force it as a 
dependency.  We are talking the selfsigned use case here, so it should 
be minimal overhead.


Anyway, in each of the service's profiles (the puppet manifests) I'm 
setting up the tracking of the certificates with the certmonger's 
puppet manifest.


BR

On Tue, Jun 21, 2016 at 5:39 PM, Adam Young > wrote:


When deploying the overcloud with TLS, the current "no additional
technology" approach is to use opensssl and self signed. While
this works for a Proof of concept, it does not make sense if the
users need to access the resources from remote systems.

It seems to me that the undercloud, as the system of record for
deploying the overcloud, should be responsible for centralizing
the signing of certificates.

When deploying a service, the puppet module sure trigger a getcert
call, which registers the cert with  Certmonger. Certmonger is
responsible for making sure the CSR gets to the signing authority,
and fetching the cert.

Certmonger works via helper apps.  While there is currently a
"self signed" helper, this does not do much if two or more systems
need to have the same CA sign their certs.

It would be fairly simple to write a certmonger helper program
that sends a CSR from a controller or compute node to the
undercloud, has the Heat instance on the undercloud validate the
request, and then pass it on to the signing application.

I'm not really too clear on how callbacks are  done from the
os-collect-config processes to Heat, but I am guessing it is some
form of Rest API that could be reused for this work flow?


I would see this as the lowest level of deployment.  We can make
use of Anchor or Dogtag helper apps already.  This might also
prove a decent middleground for people that need an automated
approach to tie in with a third party CA, where they need some
confirmation from the deployment process that the data in the CSR
is valid and should be signed.

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

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




--
Juan Antonio Osorio R.
e-mail: jaosor...@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] [Neutron] Elevating context to remove subnets created by admin

[Ihar Hrachyshka]

> On 21 Jun 2016, at 08:47, Armando M.  wrote:
> 
> 
> 
> On 20 June 2016 at 18:41, Carl Baldwin  wrote:
> Somehow, this thread hid from me for a couple of weeks.  I just
> reviewed something relevant to this here [1].  It proposes adding
> tenant id to segment.  But, it also enforces that tenant id is the
> same as that of the network owning the segment.  So, I say why store
> it at all?
> 
> I would argue that subnet should also not have a tenant_id and should
> just inherit it from the network.
> 
> It seems it may potentially limit the ability to describe ownership. 
> Virtually all Neutron models have it. Not sure I see the value in its absence.

In QoS, we actually removed the attribute from QosRule based models in the 
early phase of feature development, for reasons similar to Carl’s. We now have 
an issue updating rules due to the way controller behaves. The issue is not 
fixed just yet, but I think this discussion in gerrit is very relevant to the 
topic:

https://review.openstack.org/#/c/244680/1/neutron/api/v2/base.py

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] [Tripleo] X509 Management

[Juan Antonio Osorio]

Adam, this is pretty much the proposal for TLS for the internal services
(which you were added already as a reviewer for the spec)
https://review.openstack.org/#/c/282307/
The services in the overcloud fetching their certificates via certmonger is
actually work in progress, which you could review here:
https://review.openstack.org/#/q/status:open+topic:bp/tls-via-certmonger
Only thing is that currently this approach assumes FreeIPA, so the nodes
need to be registered beforehand (and then trigger self-enrollment via some
hooks).
Also, the spec that I'm pointing to doesn't require the CA to be the in
undercloud and it could be another node. But hey, if we could deploy Anchor
on the Undercloud, then that could be used, so we wouldn't need another
node for this means.

Anyway, in each of the service's profiles (the puppet manifests) I'm
setting up the tracking of the certificates with the certmonger's puppet
manifest.

BR

On Tue, Jun 21, 2016 at 5:39 PM, Adam Young  wrote:

> When deploying the overcloud with TLS, the current "no additional
> technology" approach is to use opensssl and self signed.  While this works
> for a Proof of concept, it does not make sense if the users need to access
> the resources from remote systems.
>
> It seems to me that the undercloud, as the system of record for deploying
> the overcloud, should be responsible for centralizing the signing of
> certificates.
>
> When deploying a service, the puppet module sure trigger a getcert call,
> which registers the cert with  Certmonger.  Certmonger is responsible for
> making sure the CSR gets to the signing authority, and fetching the cert.
>
> Certmonger works via helper apps.  While there is currently a "self
> signed" helper, this does not do much if two or more systems need to have
> the same CA sign their certs.
>
> It would be fairly simple to write a certmonger helper program that sends
> a CSR from a controller or compute node to the undercloud, has the Heat
> instance on the undercloud validate the request, and then pass it on to the
> signing application.
>
> I'm not really too clear on how callbacks are  done from the
> os-collect-config processes to Heat, but I am guessing it is some form of
> Rest API that could be reused for this work flow?
>
>
> I would see this as the lowest level of deployment.  We can make use of
> Anchor or Dogtag helper apps already.  This might also prove a decent
> middleground for people that need an automated approach to tie in with a
> third party CA, where they need some confirmation from the deployment
> process that the data in the CSR is valid and should be signed.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@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

Re: [openstack-dev] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Clint Byrum]

Excerpts from Jay Pipes's message of 2016-06-21 14:20:07 -0400:
> On 06/21/2016 02:01 PM, Andre Florath wrote:
> > Hello Jay,
> >
> > Yes - the partition alignment is a problem:
> > grub2 needs at least 63 blocks between the MBR and the first
> > partition.  Here for you the partition directly starts at block 1,
> > therefore grub has no way to put its data on the disk.
> >
> > The root cause is, that all the partitioning tools I found (like
> > parted or sfdisk) make some 'optimization': they do not what you
> > state but what they think you want. (And I have the impression that
> > their 'thinking' includes the moon phases and the biorhythm of the
> > user :-) .)
> >
> > Example in your case: sfdisk called with '1 - - *' creates on Ubuntu
> > Xenial a partition starting from block 1. On Debian 8.4 (my
> > development machine) it creates a partition starting from 2087.  This
> > gives some room for grub, but it horrible when it comes to alignment.
> >
> > Some possible workarounds:
> > o Use another host for creating the Ubuntu VM
> >(and hope, that sfdisk behaves 'better'.)
> > o Use a more recent version of diskimage-builder:
> >some time ago 'sfdisk' was replaced by 'parted'
> >(and hope, that 'parted' does a 'better' job for you).
> > o Under Ubuntu Xenial execute with 1.0.0 installed:
> >$ sudo vi 
> > /usr/share/diskimage-builder/elements/vm/block-device.d/10-partition
> >In line 23 replace
> >   1 - - *
> >with
> >   2048 - - *
> >(Note that this really only works on Ubuntu Xenial.)
> >
> > Hope this works and helps - was not able to test these things.
> >
> > If you are interested in some more background information:
> > I stumbled over the mostly random behavior of these tools last week.
> > One aspect is, that they optimize things for the current system (e.g.
> > reading some kernel parameters; especially IO buffer sizes).  These
> > sizes can be completely different on the target system - which might
> > lead to very poor disk performance.
> > During the last days I reworked my patch (which originally used
> > parted) to directly write the needed info to the boot records. [1]
> > More details can be found in the comments of MBR.py [2].
> >
> > Kind regards
> >
> > Andre
> 
> Thanks for the great information and help, all! I upgraded dib to 1.17, 
> re-ran the same command et voila, problem solved. :)
> 
> So, looks like parted vs. sfdisk is indeed the issue, and is solved in 
> modern dib versions. (Time to update Xenial's PPA for dib? ;)
> 

Just looks like it hasn't been uploaded in a while:

https://tracker.debian.org/pkg/python-diskimage-builder

Once 1.17+ gets into yakkety (The future Ubuntu 16.10) we can propose it
for xenial-backports.

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

Re: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Cathy Zhang]

Hi MartinX,

I sent you a reply on 6/14. 

Cathy

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Thursday, June 16, 2016 4:49 AM
To: 'openstack-dev@lists.openstack.org'
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with 
multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated 
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 
(one for ingress port, one for egress port) are connected to the tenants 
networks. I know that all three instances can share one network but a use case 
I am trying to implement requires that every instance has it's separated 
network and there is a different network for ingress and egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 (4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow 
classifier that matches all traffic going from VMSRC to VMDST 
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32 
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group 
containing this port pair and a port chain containing this port pair group and 
flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered 
through the VMSFC (where just the ip_forwarding is set to 1) and forwarded back 
through the p3 port to the ROUTER.  The router finds out that there are packets 
with source address 1.1.1.1 coming from port where is should not (the router 
expects those packets from the net1 interface), they don't pass the reverse 
path filter and the router drops them.

It works when I set the rp_filter off via sysctl command in the router 
namespace on the controller. But I don't want to do this -- I expect the sfc to 
work without such changes.

Is such topology supported? What should the topology look like?

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, and 
add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks respectivelly 
and don't connect them anyhow to the ROUTER nor the rest of the topology, the 
OVS is able to send the traffic to the p2 port on the ingress side. However, on 
the egress side the packet is routed to the ROUTER3 which drops it as it 
doesn't have any route for it.

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited Registered in Ireland Registered 
Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 
308263


This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.


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

Please see inline. 

Thanks,
Cathy 

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Tuesday, June 14, 2016 9:07 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with 
multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated 
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 
(one for ingress port, one for egress port) are connected to the tenants 
networks. I know that all three instances can share one network but a 

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Jay Pipes's message of 2016-06-21 12:47:46 -0400:
> On 06/21/2016 04:25 AM, Chris Dent wrote:
> > However, I worry deeply that it could become astronauts with finger
> > paints.
> 
> Yes. This.
> 
> I will happily take software design suggestions from people that 
> demonstrate with code and benchmarks that their suggestion actually 
> works outside of the theoretical/academic/MartinFowler landscape and 
> actually solves a real problem better than existing code.
> 

So, I want to be careful not to descend too far into reductionism.
Nobody is suggesting that an architecture WG goes off into the corner
and applies theory to problems without practical application.

However, some things aren't measured in how fast, or even how reliable
a piece of code is. Some things are measured in how understandable the
actual code and deployment is.

If we architect a DLM solution, refactor out all of the one-off DLM-esque
things, and performance and measured reliability stay flat, did we fail?
What about when the locks break, and an operator has _one_ way to fix
locks, instead of 5? How do we measure that?

So I think what I want to focus on is: We have to have some real basis
on which to agree that an architecture that is selected is worth the
effort to refactor things around it. But I can't promise that every
problem has an objectively measurable solution. Part of the point of
having a working group is to develop a discipline for evaluating hard
problems like that.

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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Jay Pipes's message of 2016-06-21 13:29:32 -0400:
> On 06/21/2016 12:53 PM, Doug Wiegley wrote:
> > Don’t get me wrong, I welcome this initiative. I find it mildly
> > disconcerting that the folks that I thought we were electing to fill
> > this role will instead be filled by others, but the vacuum does need
> > to be filled, and I thank Clint for stepping up.
> 
> I don't particularly think it's a vacuum that can be filled by a small 
> group of "architects". My experience is that unless said architects are 
> actually involved in building the software at hand and have a good 
> understanding of why certain design choices were originally made in the 
> various projects, the end deliverable of such a group tends to be the 
> software equivalent of silly putty -- fun to play with but in the end, 
> relatively free of practical value.
> 

I so agree with this. I don't want this group to turn into an ivory
tower shaped fountain of suggestions. That is my nightmare actually!

What I want it to be is a group that facilitates the people who build
the components of the system coming together to collaborate on large
refactoring efforts and improving our ability to design the system
together, rather than in silos.

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

Re: [openstack-dev] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Jay Pipes]

On 06/21/2016 02:01 PM, Andre Florath wrote:

Hello Jay,

Yes - the partition alignment is a problem:
grub2 needs at least 63 blocks between the MBR and the first
partition.  Here for you the partition directly starts at block 1,
therefore grub has no way to put its data on the disk.

The root cause is, that all the partitioning tools I found (like
parted or sfdisk) make some 'optimization': they do not what you
state but what they think you want. (And I have the impression that
their 'thinking' includes the moon phases and the biorhythm of the
user :-) .)

Example in your case: sfdisk called with '1 - - *' creates on Ubuntu
Xenial a partition starting from block 1. On Debian 8.4 (my
development machine) it creates a partition starting from 2087.  This
gives some room for grub, but it horrible when it comes to alignment.

Some possible workarounds:
o Use another host for creating the Ubuntu VM
   (and hope, that sfdisk behaves 'better'.)
o Use a more recent version of diskimage-builder:
   some time ago 'sfdisk' was replaced by 'parted'
   (and hope, that 'parted' does a 'better' job for you).
o Under Ubuntu Xenial execute with 1.0.0 installed:
   $ sudo vi 
/usr/share/diskimage-builder/elements/vm/block-device.d/10-partition
   In line 23 replace
  1 - - *
   with
  2048 - - *
   (Note that this really only works on Ubuntu Xenial.)

Hope this works and helps - was not able to test these things.

If you are interested in some more background information:
I stumbled over the mostly random behavior of these tools last week.
One aspect is, that they optimize things for the current system (e.g.
reading some kernel parameters; especially IO buffer sizes).  These
sizes can be completely different on the target system - which might
lead to very poor disk performance.
During the last days I reworked my patch (which originally used
parted) to directly write the needed info to the boot records. [1]
More details can be found in the comments of MBR.py [2].

Kind regards

Andre


Thanks for the great information and help, all! I upgraded dib to 1.17, 
re-ran the same command et voila, problem solved. :)


So, looks like parted vs. sfdisk is indeed the issue, and is solved in 
modern dib versions. (Time to update Xenial's PPA for dib? ;)


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] [all] Proposal: Architecture Working Group

[Doug Wiegley]

> On Jun 21, 2016, at 11:29 AM, Jay Pipes  wrote:
> 
> On 06/21/2016 12:53 PM, Doug Wiegley wrote:
>>> On Jun 21, 2016, at 2:56 AM, Thierry Carrez 
>>> wrote:
>>> Chris Dent wrote:
 On Mon, 20 Jun 2016, Doug Wiegley wrote:
> So, it sounds like you’ve just described the job of the TC. And
> they have so far refused to define OpenStack, leading to a
> series of derivative decisions that seem … inconsistent over
> time.
 
 Thanks for writing down what I was thinking. I agree that
 OpenStack needs some architectural vision, direction, leadership,
 call it what you will. Every time I've voted for the _Technical_
 Committee that leadership is what I've wanted my vote to be
 creating.
>>> 
>>> The TC is a representative body which is elected to make top-down
>>> decisions on OpenStack. However, as much as our community loves the
>>> idea of "technical leadership" and "vision", they hate the top-down
>>> decisions that come with it (especially when that top-down decision
>>> doesn't go their way). They prefer bottom-up consensus.
>>> 
>>> So I'd argue that you need both. You need the TC whenever a hard
>>> call has to be made, but in order to minimize the number of those
>>> hard calls (and favor consensus building) you also need working
>>> groups to build a bottom-up reasonable way forward.
>> 
>> This reads very strange to me, as I’d expect a group of technical
>> leaders to both make hard calls *and* to be able to build consensus
>> on overall direction and vision. They’re two sides of the same coin.
>> What is it about our process that means the TC can’t build consensus
>> on direction, but can only impose its will? I expect you didn’t mean
>> it to sound that way, though. Is the workload too high on the
>> bookkeeping to prevent the vision building? Are we too afraid of the
>> implications of defining ‘what is openstack?’, and what it might mean
>> to existing projects and the community? I’d think that in the
>> long-run, it’d prevent seemingly unrelated topics from seeming to go
>> sideways so often, and prevent a lot of these “hard calls”.
> 
> Perhaps you weren't around for the endless (and pointless) discussions around 
> what is "the core of OpenStack"? Or you weren't around for the endless (and 
> conflicting, contradictory, and religious) battles that were waged during the 
> old "incubation" and "graduation" procedures?
> 
> Ask Clint, Flavio and Devananda how fruitful the Marconi/Zaqar "architectural 
> review" by the TC was.

That would be interesting to hear, and how this group would avoid and/or help 
such issues.

> 
>> But, I’m also on the fringe that is very ready to call the “big tent”
>> a failed experiment in attempting to avoid hard calls, too.
> 
> That's because you think the big tent initiative is something that it is not.
> 
> And we've had this conversation before, but you insist on equating the big 
> tent initiative with the TC broadening what its definition of OpenStack was. 
> And that's not what the big tent initiative was, as I've said repeatedly.
> 
> The big tent initiative was specifically to change from a subjective set of 
> requirements that a project must meet in order to be "part of OpenStack" into 
> an objective set of requirements.

Wait, wait, wait. The TC has a definition of OpenStack?  Oooh, what is it?

And if we can’t answer that, how can there be objective criteria to meet an 
undefined quantity?  Oh wait, that’s what the tent is today. Except Go, of 
course.

This is tangent from the main thread topic, so I’ll let it go.

Thanks,
doug

> 
> We removed the subjective, bike-shedding, and cringe-inducing "graduation 
> review" from the application process and instead focused on documenting a 
> clear set of objective requirements that projects could obligate themselves 
> to meeting if they wanted to "be part of OpenStack".
> 
 It may be that an architecture working group can provide some
 guidance that people will find useful. Against the odds I think
 those of us in the API-WG have actually managed to have a
 positive influence. We've not shaken things down to the
 foundations from which a great a glorious future may be born -- a
 lot of compromises have been made and not everybody wants to play
 along -- but things are going in the right direction, for some
 people, in some projects. Maybe a similar thing can happen with
 architecture.
>>> 
>>> That is my hope. I see the API WG and the Architecture WG as groups
>>> of experts in specific domains preparing recommendations and
>>> long-term plans. They don't have authority to force them onto
>>> projects. Ideally projects adopt them because they see them as the
>>> right way to do things.
>>> 
>>> And for the very few things that the TC deems necessary for
>>> OpenStack and where bottom-up didn't get it in a specific project
>>> (if all else fails), the TC can make a top-down request to a

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Ian Cordasco's message of 2016-06-21 11:12:40 -0500:
>  
> 
> -Original Message-
> From: Michael Krotscheck 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: June 21, 2016 at 10:18:25
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject:  Re: [openstack-dev] [all] Proposal: Architecture Working Group
> 
> > On Mon, Jun 20, 2016 at 10:59 AM Clint Byrum wrote:
> >  
> > >
> > > As you should be, and we all must be. It's not going to happen if we
> > > just dream it. That's kind of the point. Let's write down a design _for
> > > the group that writes down designs_.
> > >
> >  
> > If I had any confidence that this group would have a significant impact on
> > making OpenStack more consistent, easy to work on, and easier to build apps
> > against, I'd be happy to help out.
> >  
> > The only thing that would give me that confidence is if the WG charter had
> > a TC-enforced section of: "If you do not implement this *thing* within two
> > cycles, your project will get kicked out of OpenStack".
> 
> I don't think that will or *should* ever happen. The documents produced by 
> this WG, to me, would be the set of best practices that should be aimed for, 
> not mandatory. Forcing someone to refactor some complex piece of architecture 
> in their project in < 1 year so the project can remain part of OpenStack 
> seems like someone begging for horrible bugs and regressions in critical 
> behaviour.
> 
> This is worse than saying "All projects should stop disabling hacking rules 
> in two cycles or they'll stop receiving OpenStack Infra resources for 
> testing." or "All projects need to write new versions of their API just to 
> conform with the API WG."
> 

Just to be clear, I'm thinking more "This is how a thing should work",
not "best practices". The difference being that we'd write down something
like " message busses should look like X, Y, or Z based on factors a, b,
and/or c", and then we'd actually go fix or document the divergent cases
in OpenStack.

A best practices group would not actually fix anything IMO. It has to be
a group of action. Of course, we'll ask for help from any project teams
that are involved, and coordinate on things like release schedules so
we don't complicate short term plans. But I don't want this to just be a
standards body. I want this to be the group that gets the ball rolling,
and then helps it keep rolling.

There's no such thing as a perfect system, so we need to work toward
a process that produces _good_ results. Enforcement without merit will
just drive a wedge into that process.

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

Re: [openstack-dev] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Andre Florath]

Hello Jay,

Yes - the partition alignment is a problem:
grub2 needs at least 63 blocks between the MBR and the first
partition.  Here for you the partition directly starts at block 1,
therefore grub has no way to put its data on the disk.

The root cause is, that all the partitioning tools I found (like
parted or sfdisk) make some 'optimization': they do not what you
state but what they think you want. (And I have the impression that
their 'thinking' includes the moon phases and the biorhythm of the
user :-) .)

Example in your case: sfdisk called with '1 - - *' creates on Ubuntu
Xenial a partition starting from block 1. On Debian 8.4 (my
development machine) it creates a partition starting from 2087.  This
gives some room for grub, but it horrible when it comes to alignment.

Some possible workarounds:
o Use another host for creating the Ubuntu VM
  (and hope, that sfdisk behaves 'better'.)
o Use a more recent version of diskimage-builder:
  some time ago 'sfdisk' was replaced by 'parted'
  (and hope, that 'parted' does a 'better' job for you).
o Under Ubuntu Xenial execute with 1.0.0 installed:
  $ sudo vi /usr/share/diskimage-builder/elements/vm/block-device.d/10-partition
  In line 23 replace
 1 - - *
  with
 2048 - - *
  (Note that this really only works on Ubuntu Xenial.)

Hope this works and helps - was not able to test these things.

If you are interested in some more background information:
I stumbled over the mostly random behavior of these tools last week.
One aspect is, that they optimize things for the current system (e.g.
reading some kernel parameters; especially IO buffer sizes).  These
sizes can be completely different on the target system - which might
lead to very poor disk performance.
During the last days I reworked my patch (which originally used
parted) to directly write the needed info to the boot records. [1]
More details can be found in the comments of MBR.py [2].

Kind regards

Andre

[1] https://review.openstack.org/#/c/322671/
[2] 
https://review.openstack.org/#/c/322671/7/diskimage_builder/block_device/level1/MBR.py


__
OpenStack Development Mailing List (not for 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][LBaaS][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used?

[Jiahao Liang]

Thank you the info Lubosz.

On Fri, Jun 17, 2016 at 5:01 PM, Kosnik, Lubosz 
wrote:

> Here is a bug for that - https://bugs.launchpad.net/octavia/+bug/1585804
> You’re more than welcome to fix this issue.
>
> Lubosz Kosnik
> Cloud Software Engineer OSIC
> lubosz.kos...@intel.com
>
> On Jun 17, 2016, at 6:37 PM, Jiahao Liang 
> wrote:
>
> Added more related topics to the original email.
>
> -- Forwarded message --
> From: Jiahao Liang (Frankie) 
> Date: Fri, Jun 17, 2016 at 4:30 PM
> Subject: [openstack-dev][Octavia]In amphora plugin_vip(), why cidr and
> gateway are required but not used?
> To: openstack-dev@lists.openstack.org
>
>
> Hi community,
>
> I am going over the Octavia amphora backend code. There is one thing
> really confused me. In
> https://github.com/openstack/octavia/blob/stable/mitaka/octavia/amphorae/backends/agent/api_server/plug.py#L45,
> plug_vip() method doesn't use the cidr and gateway from the REST request.
> But in the haproxy amphora api, those two fields are required values (an
> assert
> 
>  will
> perform on the server).
>
> What is the design considerations for this api? Could we safely remove
> these two values to avoid ambiguity?
>
> Thank you,
> Jiahao Liang
> __
> OpenStack Development Mailing List (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] [all] Proposal: Architecture Working Group

[Jay Pipes]

On 06/21/2016 12:53 PM, Doug Wiegley wrote:

On Jun 21, 2016, at 2:56 AM, Thierry Carrez 
wrote:
Chris Dent wrote:

On Mon, 20 Jun 2016, Doug Wiegley wrote:

So, it sounds like you’ve just described the job of the TC. And
they have so far refused to define OpenStack, leading to a
series of derivative decisions that seem … inconsistent over
time.


Thanks for writing down what I was thinking. I agree that
OpenStack needs some architectural vision, direction, leadership,
call it what you will. Every time I've voted for the _Technical_
Committee that leadership is what I've wanted my vote to be
creating.


The TC is a representative body which is elected to make top-down
decisions on OpenStack. However, as much as our community loves the
idea of "technical leadership" and "vision", they hate the top-down
decisions that come with it (especially when that top-down decision
doesn't go their way). They prefer bottom-up consensus.

So I'd argue that you need both. You need the TC whenever a hard
call has to be made, but in order to minimize the number of those
hard calls (and favor consensus building) you also need working
groups to build a bottom-up reasonable way forward.


This reads very strange to me, as I’d expect a group of technical
leaders to both make hard calls *and* to be able to build consensus
on overall direction and vision. They’re two sides of the same coin.
What is it about our process that means the TC can’t build consensus
on direction, but can only impose its will? I expect you didn’t mean
it to sound that way, though. Is the workload too high on the
bookkeeping to prevent the vision building? Are we too afraid of the
implications of defining ‘what is openstack?’, and what it might mean
to existing projects and the community? I’d think that in the
long-run, it’d prevent seemingly unrelated topics from seeming to go
sideways so often, and prevent a lot of these “hard calls”.


Perhaps you weren't around for the endless (and pointless) discussions 
around what is "the core of OpenStack"? Or you weren't around for the 
endless (and conflicting, contradictory, and religious) battles that 
were waged during the old "incubation" and "graduation" procedures?


Ask Clint, Flavio and Devananda how fruitful the Marconi/Zaqar 
"architectural review" by the TC was.



But, I’m also on the fringe that is very ready to call the “big tent”
a failed experiment in attempting to avoid hard calls, too.


That's because you think the big tent initiative is something that it is 
not.


And we've had this conversation before, but you insist on equating the 
big tent initiative with the TC broadening what its definition of 
OpenStack was. And that's not what the big tent initiative was, as I've 
said repeatedly.


The big tent initiative was specifically to change from a subjective set 
of requirements that a project must meet in order to be "part of 
OpenStack" into an objective set of requirements.


We removed the subjective, bike-shedding, and cringe-inducing 
"graduation review" from the application process and instead focused on 
documenting a clear set of objective requirements that projects could 
obligate themselves to meeting if they wanted to "be part of OpenStack".



It may be that an architecture working group can provide some
guidance that people will find useful. Against the odds I think
those of us in the API-WG have actually managed to have a
positive influence. We've not shaken things down to the
foundations from which a great a glorious future may be born -- a
lot of compromises have been made and not everybody wants to play
along -- but things are going in the right direction, for some
people, in some projects. Maybe a similar thing can happen with
architecture.


That is my hope. I see the API WG and the Architecture WG as groups
of experts in specific domains preparing recommendations and
long-term plans. They don't have authority to force them onto
projects. Ideally projects adopt them because they see them as the
right way to do things.

And for the very few things that the TC deems necessary for
OpenStack and where bottom-up didn't get it in a specific project
(if all else fails), the TC can make a top-down request to a
project to do things a certain way. The project can them either
comply or reject the TC oversight and become an unofficial
project.


Don’t get me wrong, I welcome this initiative. I find it mildly
disconcerting that the folks that I thought we were electing to fill
this role will instead be filled by others, but the vacuum does need
to be filled, and I thank Clint for stepping up.


I don't particularly think it's a vacuum that can be filled by a small 
group of "architects". My experience is that unless said architects are 
actually involved in building the software at hand and have a good 
understanding of why certain design choices were originally made in the 
various projects, the end deliverable of such a group tends to be the 
software 

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Doug Wiegley]

> On Jun 21, 2016, at 2:56 AM, Thierry Carrez  wrote:
> 
> Chris Dent wrote:
>> On Mon, 20 Jun 2016, Doug Wiegley wrote:
>>> So, it sounds like you’ve just described the job of the TC. And they
>>> have so far refused to define OpenStack, leading to a series of
>>> derivative decisions that seem … inconsistent over time.
>> 
>> Thanks for writing down what I was thinking. I agree that OpenStack
>> needs some architectural vision, direction, leadership, call it what
>> you will. Every time I've voted for the _Technical_ Committee that
>> leadership is what I've wanted my vote to be creating.
> 
> The TC is a representative body which is elected to make top-down decisions 
> on OpenStack. However, as much as our community loves the idea of "technical 
> leadership" and "vision", they hate the top-down decisions that come with it 
> (especially when that top-down decision doesn't go their way). They prefer 
> bottom-up consensus.
> 
> So I'd argue that you need both. You need the TC whenever a hard call has to 
> be made, but in order to minimize the number of those hard calls (and favor 
> consensus building) you also need working groups to build a bottom-up 
> reasonable way forward.

This reads very strange to me, as I’d expect a group of technical leaders to 
both make hard calls *and* to be able to build consensus on overall direction 
and vision. They’re two sides of the same coin. What is it about our process 
that means the TC can’t build consensus on direction, but can only impose its 
will? I expect you didn’t mean it to sound that way, though. Is the workload 
too high on the bookkeeping to prevent the vision building? Are we too afraid 
of the implications of defining ‘what is openstack?’, and what it might mean to 
existing projects and the community? I’d think that in the long-run, it’d 
prevent seemingly unrelated topics from seeming to go sideways so often, and 
prevent a lot of these “hard calls”.

But, I’m also on the fringe that is very ready to call the “big tent” a failed 
experiment in attempting to avoid hard calls, too.

> 
>> It may be that an architecture working group can provide some
>> guidance that people will find useful. Against the odds I think
>> those of us in the API-WG have actually managed to have a positive
>> influence. We've not shaken things down to the foundations from
>> which a great a glorious future may be born -- a lot of compromises
>> have been made and not everybody wants to play along -- but things
>> are going in the right direction, for some people, in some projects.
>> Maybe a similar thing can happen with architecture.
> 
> That is my hope. I see the API WG and the Architecture WG as groups of 
> experts in specific domains preparing recommendations and long-term plans. 
> They don't have authority to force them onto projects. Ideally projects adopt 
> them because they see them as the right way to do things.
> 
> And for the very few things that the TC deems necessary for OpenStack and 
> where bottom-up didn't get it in a specific project (if all else fails), the 
> TC can make a top-down request to a project to do things a certain way. The 
> project can them either comply or reject the TC oversight and become an 
> unofficial project.

Don’t get me wrong, I welcome this initiative. I find it mildly disconcerting 
that the folks that I thought we were electing to fill this role will instead 
be filled by others, but the vacuum does need to be filled, and I thank Clint 
for stepping up.

Thanks,
doug


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


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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Jay Pipes]

On 06/21/2016 04:25 AM, Chris Dent wrote:

However, I worry deeply that it could become astronauts with finger
paints.


Yes. This.

I will happily take software design suggestions from people that 
demonstrate with code and benchmarks that their suggestion actually 
works outside of the theoretical/academic/MartinFowler landscape and 
actually solves a real problem better than existing code.


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] [Neutron] Elevating context to remove subnets created by admin

[Carl Baldwin]

On Tue, Jun 21, 2016 at 12:47 AM, Armando M.  wrote:
> It seems it may potentially limit the ability to describe ownership.
> Virtually all Neutron models have it. Not sure I see the value in its
> absence.

I'm just saying that I don't see value in its presence.  The value
that I see in its absence is that this bug would never have happened.
I'm not sure I'm motivated enough to do anything about it at this
point in time though.

Carl

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

Re: [openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.

[Adam Young]

On 06/21/2016 08:43 AM, Markus Zoeller wrote:

A reminder that this will happen in ~2 weeks.

Please note that you can spare bug reports if you leave a comment there
which says one of these (case-sensitive flags):
* CONFIRMED FOR: NEWTON
* CONFIRMED FOR: MITAKA
* CONFIRMED FOR: LIBERTY

On 23.05.2016 13:02, Markus Zoeller wrote:

TL;DR: Automatic closing of 185 bug reports which are older than 18
months in the week R-13. Skipping specific bug reports is possible. A
bug report comment explains the reasons.


I'd like to get rid of more clutter in our bug list to make it more
comprehensible by a human being. For this, I'm targeting our ~185 bug
reports which were reported 18 months ago and still aren't in progress.
That's around 37% of open bug reports which aren't in progress. This
post is about *how* and *when* I do it. If you have very strong reasons
to *not* do it, let me hear them.

When

I plan to do it in the week after the non-priority feature freeze.
That's week R-13, at the beginning of July. Until this date you can
comment on bug reports so they get spared from this cleanup (see below).
Beginning from R-13 until R-5 (Newton-3 milestone), we should have
enough time to gain some overview of the rest.

I also think it makes sense to make this a repeated effort, maybe after
each milestone/release or monthly or daily.

How
---
The bug reports which will be affected are:
* in status: [new, confirmed, triaged]
* AND without assignee
* AND created at: > 18 months
A preview of them can be found at [1].

You can spare bug reports if you leave a comment there which says
one of these (case-sensitive flags):
* CONFIRMED FOR: NEWTON
* CONFIRMED FOR: MITAKA
* CONFIRMED FOR: LIBERTY

The expired bug report will have:
* status: won't fix
* assignee: none
* importance: undecided
* a new comment which explains *why* this was done

The comment the expired bug reports will get:
 This is an automated cleanup. This bug report got closed because
 it is older than 18 months and there is no open code change to
 fix this. After this time it is unlikely that the circumstances
 which lead to the observed issue can be reproduced.
 If you can reproduce it, please:
 * reopen the bug report
 * AND leave a comment "CONFIRMED FOR: "
   Only still supported release names are valid.
   valid example: CONFIRMED FOR: LIBERTY
   invalid example: CONFIRMED FOR: KILO
 * AND add the steps to reproduce the issue (if applicable)


Let me know if you think this comment gives enough information how to
handle this situation.


References:
[1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired




DONT TOUCH BUG 968696!


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

Re: [openstack-dev] [Tripleo] X509 Management

[Adam Young]

On 06/21/2016 11:26 AM, John Dennis wrote:

On 06/21/2016 10:55 AM, Ian Cordasco wrote:

-Original Message-
From: Adam Young 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List 


Subject:  [openstack-dev] [Tripleo] X509 Management


When deploying the overcloud with TLS, the current "no additional
technology" approach is to use opensssl and self signed. While this
works for a Proof of concept, it does not make sense if the users need
to access the resources from remote systems.

It seems to me that the undercloud, as the system of record for
deploying the overcloud, should be responsible for centralizing the
signing of certificates.

When deploying a service, the puppet module sure trigger a getcert 
call,

which registers the cert with Certmonger. Certmonger is responsible
for making sure the CSR gets to the signing authority, and fetching the
cert.

Certmonger works via helper apps. While there is currently a "self
signed" helper, this does not do much if two or more systems need to
have the same CA sign their certs.

It would be fairly simple to write a certmonger helper program that
sends a CSR from a controller or compute node to the undercloud, has 
the

Heat instance on the undercloud validate the request, and then pass it
on to the signing application.

I'm not really too clear on how callbacks are done from the
os-collect-config processes to Heat, but I am guessing it is some form
of Rest API that could be reused for this work flow?


I would see this as the lowest level of deployment. We can make use of
Anchor or Dogtag helper apps already. This might also prove a decent
middleground for people that need an automated approach to tie in 
with a

third party CA, where they need some confirmation from the deployment
process that the data in the CSR is valid and should be signed.


I'm not familiar with TripleO or it's use of puppet, but I would
strongly advocate for Anchor (or DogTag) to be the recommended
solution. OpenStack Ansible has found it a little bit of an annoyance
to generate and distribute self-signed certificates.


Ah, but the idea is that certmonger is a front to whatever CA you 
chose to use, it provides a consistent interface to a range of CA's as 
well as providing functionality not present in most CA's, for instance 
the ability detect when certs need renewal etc. So the idea would be 
certmonger+Dogtag or certmongner+Anchor, or certmonger+XXX


Exactly.  This allows the interface from Tripleo to be the same 
regardless of the CA.



I am looking for guidance from the Tripleo/Heat team on how to structure 
the certmonger helper app.



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

Re: [openstack-dev] [Monasca] Locked (latched) alarms

[Hochmuth, Roland M]

Hi Witek, Thanks for the blueprint. We can review tomorrow if you would like. 
Personally, I like the term "locked". The alarm definition makes more sense 
(option 2). I don't think an operator will want to lock/latch an alarm 
sub-expression. The operator will want to lock/latch an entire alarm. 
Therefore, what seems to make sense is adding the new capability to the alarm 
definition as it applies to the entire alarm. We had a similar internal 
discussion a couple of months ago, and that is the same conclusion that we came 
too.

Regards --Roland







On 6/21/16, 4:38 AM, "witold.be...@est.fujitsu.com" 
 wrote:

>Hello everyone,
>
>I have written a short blueprint on locked/latched alarms for Monasca [1]. The 
>functionality allows the operator to define an alarm which after transition to 
>ALARM state, stays in that state until it is manually reset.
>
>What name should we use for that? Locked, lockable, latched, sticky? Something 
>else?
>
>I would also welcome feedback on a general implementation idea. Should we make 
>it in the same way as the deterministic alarms, by extending the 
>AlarmExpression? Or would it be enough to add the property to AlarmDefinition 
>(option 2)? I tend to the second solution. The change in the logic of 
>monasca-thresh would then be limited to AlarmThresholdingBolt. 
>evaluateThreshold as far as I understand. Craig and Roland, could you comment 
>on that please?
>
>
>Cheers
>Witek
>
>
>[1] https://blueprints.launchpad.net/monasca/+spec/locked-alarms
>
>
>Witold Bedyk
>Senior Software Engineer
>
>FUJITSU Enabling Software Technology GmbH
>Schwanthalerstr. 75a, 80336 München
>
>Telefon: +49 89 360908-547
>Telefax: +49 89 360908-8547
>COINS: 7941-6547
>
>Sitz der Gesellschaft: München
>AG München, HRB 143325
>Geschäftsführer: Dr. Yuji Takada, Hans-Dieter Gatzka, Christian Menk
>
>
>__
>OpenStack Development Mailing List (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] [all] Proposal: Architecture Working Group

[Ian Cordasco]

 

-Original Message-
From: Michael Krotscheck 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: June 21, 2016 at 10:18:25
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [all] Proposal: Architecture Working Group

> On Mon, Jun 20, 2016 at 10:59 AM Clint Byrum wrote:
>  
> >
> > As you should be, and we all must be. It's not going to happen if we
> > just dream it. That's kind of the point. Let's write down a design _for
> > the group that writes down designs_.
> >
>  
> If I had any confidence that this group would have a significant impact on
> making OpenStack more consistent, easy to work on, and easier to build apps
> against, I'd be happy to help out.
>  
> The only thing that would give me that confidence is if the WG charter had
> a TC-enforced section of: "If you do not implement this *thing* within two
> cycles, your project will get kicked out of OpenStack".

I don't think that will or *should* ever happen. The documents produced by this 
WG, to me, would be the set of best practices that should be aimed for, not 
mandatory. Forcing someone to refactor some complex piece of architecture in 
their project in < 1 year so the project can remain part of OpenStack seems 
like someone begging for horrible bugs and regressions in critical behaviour.

This is worse than saying "All projects should stop disabling hacking rules in 
two cycles or they'll stop receiving OpenStack Infra resources for testing." or 
"All projects need to write new versions of their API just to conform with the 
API WG."

--  
Ian Cordasco


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

Re: [openstack-dev] [Tripleo] X509 Management

[Ian Cordasco]

-Original Message-
From: John Dennis 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: June 21, 2016 at 10:28:22
To: OpenStack Development Mailing List (not for usage questions) 
, Adam Young 
Subject:  Re: [openstack-dev] [Tripleo] X509 Management

> On 06/21/2016 10:55 AM, Ian Cordasco wrote:
> > -Original Message-
> > From: Adam Young  
> > Reply: OpenStack Development Mailing List (not for usage questions)
> >  
> > Date: June 21, 2016 at 09:40:39
> > To: OpenStack Development Mailing List  
> > Subject: [openstack-dev] [Tripleo] X509 Management
> >
> >> When deploying the overcloud with TLS, the current "no additional
> >> technology" approach is to use opensssl and self signed. While this
> >> works for a Proof of concept, it does not make sense if the users need
> >> to access the resources from remote systems.
> >>
> >> It seems to me that the undercloud, as the system of record for
> >> deploying the overcloud, should be responsible for centralizing the
> >> signing of certificates.
> >>
> >> When deploying a service, the puppet module sure trigger a getcert call,
> >> which registers the cert with Certmonger. Certmonger is responsible
> >> for making sure the CSR gets to the signing authority, and fetching the
> >> cert.
> >>
> >> Certmonger works via helper apps. While there is currently a "self
> >> signed" helper, this does not do much if two or more systems need to
> >> have the same CA sign their certs.
> >>
> >> It would be fairly simple to write a certmonger helper program that
> >> sends a CSR from a controller or compute node to the undercloud, has the
> >> Heat instance on the undercloud validate the request, and then pass it
> >> on to the signing application.
> >>
> >> I'm not really too clear on how callbacks are done from the
> >> os-collect-config processes to Heat, but I am guessing it is some form
> >> of Rest API that could be reused for this work flow?
> >>
> >>
> >> I would see this as the lowest level of deployment. We can make use of
> >> Anchor or Dogtag helper apps already. This might also prove a decent
> >> middleground for people that need an automated approach to tie in with a
> >> third party CA, where they need some confirmation from the deployment
> >> process that the data in the CSR is valid and should be signed.
> >
> > I'm not familiar with TripleO or it's use of puppet, but I would
> > strongly advocate for Anchor (or DogTag) to be the recommended
> > solution. OpenStack Ansible has found it a little bit of an annoyance
> > to generate and distribute self-signed certificates.
>  
> Ah, but the idea is that certmonger is a front to whatever CA you chose
> to use, it provides a consistent interface to a range of CA's as well as
> providing functionality not present in most CA's, for instance the
> ability detect when certs need renewal etc. So the idea would be
> certmonger+Dogtag or certmongner+Anchor, or certmonger+XXX

I didn't get that. *Starts thinking of suggesting OSA adopting certmonger*

--  
Ian Cordasco


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

Re: [openstack-dev] [puppet] Action parameter missing in generated stonith fence manifests

[Devon Mizelle]

Greetings Sofer,

Thanks for your reply.

I've went ahead and followed your instructions to file a bug here:

https://bugs.launchpad.net/puppet-pacemaker/+bug/1594870

I'll keep a watch on it!

Thanks for your help!
Devon

On Tue, Jun 21, 2016 at 9:00 AM, Sofer Athlan-Guyot  wrote:
> Hi Devon,
>
> Devon Mizelle  writes:
>
>> Greetings,
>>
>> I was directed here from #puppet-openstack to submit an e-mail.
>
> Well, the best way to have it done, would be to make bug in launchap[1]
>
> If you don't have the an account or the time time let me know I will do
> it for you, np.
>
> The patch shouldn't be a problem, but the diff here misses some bits :)
>
> Thanks,
>
> [1] https://bugs.launchpad.net/puppet-pacemaker/+bugs
>
>> Noted here, there is an 'action' parameter defined for fence_ifmib:
>>
>> https://github.com/openstack/puppet-pacemaker/blob/f62805f678f6fd8a260118279f6e0dbb05bff3d1/agent_generator/src_xml/fence_ifmib.xml#L83
>>
>> However, in the generated manifest here, it seems that the 'action'
>> parameter is missing:
>>
>> https://github.com/openstack/puppet-pacemaker/blob/f62805f678f6fd8a260118279f6e0dbb05bff3d1/manifests/stonith/fence_ifmib.pp
>>
>> It looks like the 'action' parameter is missing in every fence_*
>> manifest (and has never existed.) I need this available to me so that
>> I can override the default action of fence_ifmib (which is 'reboot')
>> and set it to 'off'.
>>
>> It looks like that in the agent_generator.rb script, action is being
>> specifically ignored in addition to 'help' and 'version' parameters.
>> I've attached a quick plain-text patch. I don't think this is the
>> norm, but considering that its such a small one word change I'm hoping
>> it would be OK.
>>
>> Thanks for your time and for a wonderful project,
>> Devon
>>
>> diff --git a/agent_generator/agent_generator.rb
>> b/agent_generator/agent_generator.rb
>> index 9c1ab0a..171ca50 100755
>> --- a/agent_generator/agent_generator.rb
>> +++ b/agent_generator/agent_generator.rb
>> @@ -40,7 +40,7 @@ class FencingMetadataParser
>>param['default'] = REXML::XPath.match(p, 
>> 'string(./content/@default)')[0]
>>param['description'] = REXML::XPath.match(p, 'string(./shortdesc)')[0]
>>## remove parameters that are not usable during automatic execution
>> -  @params.push(param) unless %w(help version
>> action).include?(param['name'])
>> +  @params.push(param) unless %w(help version).include?(param['name'])
>>  }
>>  @params
>>end
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Sofer Athlan-Guyot

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

Re: [openstack-dev] Version header for OpenStack microversion support

[Monty Taylor]

On 06/21/2016 10:27 AM, Sean Dague wrote:
> On 06/21/2016 10:47 AM, Monty Taylor wrote:
> 
>>
>> I'll agree with Clint here, and give an example.
>>
>> When I talk to Nova and get a detail record for a server, Nova talks to
>> Neutron and puts data that it receives into the addresses dict on the
>> server record. This is not the neutron data structure. In fact, it has
>> some information from the Network and some from the Port (it would be
>> helpful if it had _more_ info, but that's not the point here)
>>
>> In any case, the data structure returned by Nova is not related in any
>> way to the version of Neutron that nova is talking to - nor should it be.
>>
>> Here's an example (in yaml not json)
>>
>>   addresses:
>> GATEWAY_NET:
>> - OS-EXT-IPS-MAC:mac_addr: fa:16:3e:ea:d8:0d
>>   OS-EXT-IPS:type: fixed
>>   addr: 172.99.106.178
>>   version: 4
>>
>> If you want a neutron record, you'll talk to neutron.
> 
> That's all well and good today, with all the things that we know about
> today. And says nothing about what the Neutron API looks like in 6 years
> time. Let's say that Neutron decides in 2020 that "fixed" is a non
> meaningful name, and stops using it.
> 
> We just did a transition in Nova interacting with Glance where we *could
> not* guarantee the semantics of the interaction from before. We decided
> to *shrug* and just break it, because the only other option was to pin
> to Glance v1 API for eternity.
> 
> So just because you can't imagine a situation right now where this isn't
> a problem, doesn't mean that it's not going to hit you. And the API is a
> place where we don't really get do overs without hurting users.
> 
> ...
> 
> And getting back to the point of the argument it's all about:
> 
> OpenStack-API-Version: compute 2.11
> 
> vs.
> 
> OpenStack-API-Version: 2.11
> 
> 8 bytes to be more explicit on our ACK, and to allow flexibility for
> composite actions in the future (which may never be used, so 8 bytes is
> our cost).

I think putting compute in the argument is a GREAT idea. Sorry, I should
have been much clearer on that.

I was mostly arguing that regardless of where Nova gets its data, if I'm
talking to Nova then it's Nova's api version I care about. I think
expecting me to need to also set a neutron microversion header when
talking to nova is a _terrible_ user experience, and if neutron were to
do something that would make it unpossible for nova to fulfill its API
contract, then we, as OpenStack, should say no.

Monty

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

Re: [openstack-dev] [Kuryr][Magnum] - Kuryr nested containers and Magnum Integration

[Hongbin Lu]

Gal,

Thanks for starting this ML. Since the work involves both team, I think it is a 
good idea to start by splitting the task first. Then, we can see which items go 
to which teams. Vikas, do you mind to update this ML once the task is spitted? 
Thanks in advance.

Best regards,
Hongbin

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: June-21-16 2:14 AM
To: OpenStack Development Mailing List (not for usage questions); Vikas 
Choudhary; Antoni Segura Puimedon; Irena Berezovsky; Fawad Khaliq; Omer Anson; 
Hongbin Lu
Subject: [Kuryr][Magnum] - Kuryr nested containers and Magnum Integration

Hello all,

I am writing this out to provide awareness and hopefully get some work started
on the above topic.

We have merged a spec about supporting nested containers and integration with 
Magnum
some time ago [1] , Fawad (CCed) led this spec.

We are now seeking for volunteers to start implementing this on both Kuryr and 
the needed
parts in Magnum.

Vikas (CCed) volunteered in the last IRC meeting [2] to start and split this 
work into sub-tasks
so it will be easier to share, anyone else that is interested to join this 
effort is more then welcome to join in and contact Vikas.
I do know several other people showed interest to work on this so i hope we can 
pull everyone
together in this thread, or online at IRC.

Thanks
Gal.

[1] https://review.openstack.org/#/c/269039/
[2] 
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-06-20-14.00.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sean Dague]

On 06/21/2016 10:10 AM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2016-06-21 08:00:50 -0400:
>> On 06/21/2016 07:39 AM, Jay Pipes wrote:
>>> On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
 Le 21/06/2016 10:04, Chris Dent a écrit :
> On Mon, 20 Jun 2016, Jay Pipes wrote:
>
>> Flask seems to be the most widely used and known WSGI framework so
>> for consistency's sake, I'm recommending we just use it and not rock
>> this boat. There are more important things to get hung up on than
>> this battle right now.
>
> That seems perfectly reasonable. My main goal in starting the
> discussion was to ensure that we reach some kind of consensus,
> whatever it might be[1]. It won't be too much of an ordeal to
> turn the existing pure WSGI stuff into Flask stuff.
>
> From my standpoint doing the initial development in straight WSGI
> was a win as it allowed for a lot of clarity from the inside out.
> Now that that development has shown the shape of the API we can
> do what we need to do to make it clear from outside in.
>
> Next question: There's some support for not using Paste and
> paste.ini. Is anyone opposed to that?
>

 Given Flask is not something we support yet in Nova, could we discuss on
 that during either a Nova meeting, or maybe wait for the midcycle ?
>>>
>>> I really don't want to wait for the mid-cycle. Happy to discuss in the
>>> Nova meeting, but my preference is to have Chris just modify his patch
>>> series to use Flask now and review it.
>>>
 To be honest, Chris and you were saying that you don't like Flask, and
 I'm a bit agreeing with you. Why now it's a good possibility ?
>>>
>>> Because Doug persuaded me that the benefits of being consistent with
>>> what the community is using outweigh my (and Chris') personal misgivings
>>> about the particular framework.
>>
>> Just to be clear
>>
>> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
>>
>> Flask is used by 2 (relatively new) projects in OpenStack
>>
>> If we look at the iaas base layer:
>>
>> Keystone - custom WSGI with Routes / Paste
>> Glance - WSME + Routes / Paste
>> Cinder - custom WSGI with Routes / Paste
>> Neutron - pecan + Routes / Paste
>> Nova - custom WSGI with Routes / Paste
>>
> 
> When I see "custom WSGI" I have a few thoughts:
> 
> * custom == special snowflake. But REST API's aren't exactly novel.
> 
> * If using a framework means not writing or cargo culting any custom
> WSGI code, that seems like a win for maintainability from the get go.
> 
> * If using a framework means handling errors more consistently, that
> seems like a win for operators.
> 
> * I don't have a grasp on how much custom WSGI code is actually
> involved. That would help us all evaluate the meaning of the statements
> above (both yours, and mine).

And my point is, it's not actually much. Because you still have to do
paste, and you still have to do request validation, and you still have
to actually right controllers and views. Routes has a restful resource
model -
https://routes.readthedocs.io/en/latest/restful.html#restful-services -
which is really not more complicated than the router decorators you get
with other services.

The places that we have large complicated wsgi flows is because we
supported extensions that can modify requests/responses, or the whole
XML/JSON content switching (which was a nightmare). All of these things
are being deleted.

If you actually look at the Nova patches that Chris is building, the
logic that's the wsgi "framework" is quite small and the application
logic is pretty much what it is going to be in any framework -
https://review.openstack.org/#/c/329152/11/nova/api/openstack/placement/handlers/inventory.py

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] Does nova-compute interact with nova Db?

[Jay Pipes]

On 06/21/2016 10:07 AM, KHAN, RAO ADNAN wrote:

I want to collect an *extra_resource* info from compute node(s) and add
it in to the compute_nodes table. I like to understand how nova-compute
interacts with DB currently.


nova-compute does not interact with the database directly. Only via the 
nova.objects interfaces.


That said, please don't use extra_resources. That is for the extensible 
resource tracker which has been removed from Nova.


Can you please share information on what you are wanting to track using 
the extra_resources field?


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] Does nova-compute interact with nova Db?

[Andrey Volkov]

Hi,

nova-compute hasn't direct access to DB only scheduler, conductor and API
can use it.
See schema: http://docs.openstack.org/developer/nova/architecture.html.

I think for your case you could write some script (ansible, puppet?) to
collect data and nova-manage command to update DB.

On Tue, Jun 21, 2016 at 5:07 PM, KHAN, RAO ADNAN  wrote:

> I want to collect an *extra_resource* info from compute node(s) and add it
> in to the compute_nodes table. I like to understand how nova-compute
> interacts with DB currently.
>
>
>
> Thanks,
>
>
>
> *Rao Adnan Khan*
>
> AT Integrated Cloud (AIC) Development | SE
> Software Development & Engineering (SD)
>
> Emai: rk2...@att.com
>
> Cell phone: 972-342-5638
>
>
>
> RESTRICTED - PROPRIETARY INFORMATION
>
> This email is the property of AT and intended solely for the use of the
> addressee. If you have reason to believe you have received this in error,
> please delete this immediately; any other use, retention, dissemination,
> copying or printing of this email 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
>
>


-- 
Thanks,

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

Re: [openstack-dev] Version header for OpenStack microversion support

[Sean Dague]

On 06/21/2016 10:47 AM, Monty Taylor wrote:

> 
> I'll agree with Clint here, and give an example.
> 
> When I talk to Nova and get a detail record for a server, Nova talks to
> Neutron and puts data that it receives into the addresses dict on the
> server record. This is not the neutron data structure. In fact, it has
> some information from the Network and some from the Port (it would be
> helpful if it had _more_ info, but that's not the point here)
> 
> In any case, the data structure returned by Nova is not related in any
> way to the version of Neutron that nova is talking to - nor should it be.
> 
> Here's an example (in yaml not json)
> 
>   addresses:
> GATEWAY_NET:
> - OS-EXT-IPS-MAC:mac_addr: fa:16:3e:ea:d8:0d
>   OS-EXT-IPS:type: fixed
>   addr: 172.99.106.178
>   version: 4
> 
> If you want a neutron record, you'll talk to neutron.

That's all well and good today, with all the things that we know about
today. And says nothing about what the Neutron API looks like in 6 years
time. Let's say that Neutron decides in 2020 that "fixed" is a non
meaningful name, and stops using it.

We just did a transition in Nova interacting with Glance where we *could
not* guarantee the semantics of the interaction from before. We decided
to *shrug* and just break it, because the only other option was to pin
to Glance v1 API for eternity.

So just because you can't imagine a situation right now where this isn't
a problem, doesn't mean that it's not going to hit you. And the API is a
place where we don't really get do overs without hurting users.

...

And getting back to the point of the argument it's all about:

OpenStack-API-Version: compute 2.11

vs.

OpenStack-API-Version: 2.11

8 bytes to be more explicit on our ACK, and to allow flexibility for
composite actions in the future (which may never be used, so 8 bytes is
our cost).

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Tripleo] X509 Management

[John Dennis]

On 06/21/2016 10:55 AM, Ian Cordasco wrote:

-Original Message-
From: Adam Young 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [Tripleo] X509 Management


When deploying the overcloud with TLS, the current "no additional
technology" approach is to use opensssl and self signed. While this
works for a Proof of concept, it does not make sense if the users need
to access the resources from remote systems.

It seems to me that the undercloud, as the system of record for
deploying the overcloud, should be responsible for centralizing the
signing of certificates.

When deploying a service, the puppet module sure trigger a getcert call,
which registers the cert with Certmonger. Certmonger is responsible
for making sure the CSR gets to the signing authority, and fetching the
cert.

Certmonger works via helper apps. While there is currently a "self
signed" helper, this does not do much if two or more systems need to
have the same CA sign their certs.

It would be fairly simple to write a certmonger helper program that
sends a CSR from a controller or compute node to the undercloud, has the
Heat instance on the undercloud validate the request, and then pass it
on to the signing application.

I'm not really too clear on how callbacks are done from the
os-collect-config processes to Heat, but I am guessing it is some form
of Rest API that could be reused for this work flow?


I would see this as the lowest level of deployment. We can make use of
Anchor or Dogtag helper apps already. This might also prove a decent
middleground for people that need an automated approach to tie in with a
third party CA, where they need some confirmation from the deployment
process that the data in the CSR is valid and should be signed.


I'm not familiar with TripleO or it's use of puppet, but I would
strongly advocate for Anchor (or DogTag) to be the recommended
solution. OpenStack Ansible has found it a little bit of an annoyance
to generate and distribute self-signed certificates.


Ah, but the idea is that certmonger is a front to whatever CA you chose 
to use, it provides a consistent interface to a range of CA's as well as 
providing functionality not present in most CA's, for instance the 
ability detect when certs need renewal etc. So the idea would be 
certmonger+Dogtag or certmongner+Anchor, or certmonger+XXX

--
John

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

Re: [openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

[Monty Taylor]

On 06/21/2016 10:06 AM, Jay Faulkner wrote:
> 
> 
> On 6/17/16 3:04 PM, Joshua Harlow wrote:
>> Hi folks,
>>
>> I was noticing that its possible to do something like:
>>
>> $ nova meta josh-testr3 set "e=f"
>>
>> Then inside the VM I can do the following to eventually see that this
>> changes shows up in the instance metadata exposed at the following:
>>
>> $ curl -s http://169.254.169.254/openstack/latest/meta_data.json |
>> python -mjson.tool
>>
>> {
>> ...
>> "hostname": "josh-testr3.cloud.phx3.gdg",
>> "launch_index": 0,
>> "meta": {
>> ...
>> "e": "f",
>> ..
>>  }
>>  ...
>> }
>>
>> Now if I am using the configdrive instead of the metadata server at
>> that special/magic ip that same metadata never seems to change (I
>> assume the configdrive would have to be 'ejected' and then a new
>> configdrive created and then that configdrive 'reinserted'); was
>> anyone aware of a bug that would solve this (it does appear to be a
>> feature difference that could/should? be solved)?
>>
> I would be -1 to instituting this change as well, as it would be
> impossible for some hypervisors/drivers (such as Ironic) to implement.
> Additionally, how could you ensure the tenant OS didn't have the
> configdrive mounted or otherwise in use?

I'm going to have to agree with Jay - and I believe with something Clint
said earlier.

Use metadata/config-drive to bootstrap you. Then use your actual tools
(puppet/chef/ansible/salt/juju/cfengine) to interact with the node once
it's enrolled in whatever you use to orchestrate cloud things. The best
part about doing that is that your orchestration layer can talk to the
OpenStack APIs AND to your nodes. Most of them also support key-value
pairs, as well as updating them.

> 
>> Why this is something useful (from my view) is that we (at godaddy)
>> have a cron job that polls that metadata periodically and it generates
>> a bunch of polling traffic (especially when each VM does this) and
>> that traffic could be removed if such a 'eject' and 'reinsert' happens
>> instead (since then the cron job could become a small program that
>> listens for devices being inserted/removed and does the needed actions
>> then, which is better than polling endlessly for data that hasn't
>> changed).
>>
>> -Josh
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Michael Krotscheck]

On Mon, Jun 20, 2016 at 10:59 AM Clint Byrum  wrote:

>
> As you should be, and we all must be. It's not going to happen if we
> just dream it. That's kind of the point. Let's write down a design _for
> the group that writes down designs_.
>

If I had any confidence that this group would have a significant impact on
making OpenStack more consistent, easy to work on, and easier to build apps
against, I'd be happy to help out.

The only thing that would give me that confidence is if the WG charter had
a TC-enforced section of: "If you do not implement this *thing* within two
cycles, your project will get kicked out of OpenStack".

Michael
__
OpenStack Development Mailing List (not for 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] ability to set metadata on instances (but config drive is not updated)

[Jay Faulkner]

On 6/17/16 3:04 PM, Joshua Harlow wrote:

Hi folks,

I was noticing that its possible to do something like:

$ nova meta josh-testr3 set "e=f"

Then inside the VM I can do the following to eventually see that this 
changes shows up in the instance metadata exposed at the following:


$ curl -s http://169.254.169.254/openstack/latest/meta_data.json | 
python -mjson.tool


{
...
"hostname": "josh-testr3.cloud.phx3.gdg",
"launch_index": 0,
"meta": {
...
"e": "f",
..
 }
 ...
}

Now if I am using the configdrive instead of the metadata server at 
that special/magic ip that same metadata never seems to change (I 
assume the configdrive would have to be 'ejected' and then a new 
configdrive created and then that configdrive 'reinserted'); was 
anyone aware of a bug that would solve this (it does appear to be a 
feature difference that could/should? be solved)?


I would be -1 to instituting this change as well, as it would be 
impossible for some hypervisors/drivers (such as Ironic) to implement. 
Additionally, how could you ensure the tenant OS didn't have the 
configdrive mounted or otherwise in use?


Thanks,
Jay

Why this is something useful (from my view) is that we (at godaddy) 
have a cron job that polls that metadata periodically and it generates 
a bunch of polling traffic (especially when each VM does this) and 
that traffic could be removed if such a 'eject' and 'reinsert' happens 
instead (since then the cron job could become a small program that 
listens for devices being inserted/removed and does the needed actions 
then, which is better than polling endlessly for data that hasn't 
changed).


-Josh

__ 


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

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



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

Re: [openstack-dev] [Tripleo] X509 Management

[Ian Cordasco]

-Original Message-
From: Adam Young 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [Tripleo] X509 Management

> When deploying the overcloud with TLS, the current "no additional
> technology" approach is to use opensssl and self signed. While this
> works for a Proof of concept, it does not make sense if the users need
> to access the resources from remote systems.
>
> It seems to me that the undercloud, as the system of record for
> deploying the overcloud, should be responsible for centralizing the
> signing of certificates.
>
> When deploying a service, the puppet module sure trigger a getcert call,
> which registers the cert with Certmonger. Certmonger is responsible
> for making sure the CSR gets to the signing authority, and fetching the
> cert.
>
> Certmonger works via helper apps. While there is currently a "self
> signed" helper, this does not do much if two or more systems need to
> have the same CA sign their certs.
>
> It would be fairly simple to write a certmonger helper program that
> sends a CSR from a controller or compute node to the undercloud, has the
> Heat instance on the undercloud validate the request, and then pass it
> on to the signing application.
>
> I'm not really too clear on how callbacks are done from the
> os-collect-config processes to Heat, but I am guessing it is some form
> of Rest API that could be reused for this work flow?
>
>
> I would see this as the lowest level of deployment. We can make use of
> Anchor or Dogtag helper apps already. This might also prove a decent
> middleground for people that need an automated approach to tie in with a
> third party CA, where they need some confirmation from the deployment
> process that the data in the CSR is valid and should be signed.

I'm not familiar with TripleO or it's use of puppet, but I would
strongly advocate for Anchor (or DogTag) to be the recommended
solution. OpenStack Ansible has found it a little bit of an annoyance
to generate and distribute self-signed certificates.

--
Ian Cordasco

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

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

[Emilien Macchi]

Meeting cancelled, no topics this week.

See you next week!

On Mon, Jun 20, 2016 at 9:44 AM, Emilien Macchi <emil...@redhat.com> 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

__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[Sean Dague]

On 06/21/2016 10:11 AM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2016-06-21 09:10:00 -0400:
>> The amount of wsgi glue above Routes / Paste is pretty minimal (after
>> you get rid of all the extensions facilities).
>>
>> Templating and Session handling are things we don't need. We're not a
>> webapp, we're a REST service. Saying that using a web app framework is
>> better than a little bit of wsgi glue seems weird to me.
>>
> 
> Actually we do have sessions. We just call them "tokens".

But that's not traditional sessions that use cookies and keep some
persistent state over the course of the session (besides auth). Which is
the kind of session support that these frameworks tend to provide.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [stable] [manila] Stable check of openstack/manila failed

[Ian Cordasco]

-Original Message-
From: A mailing list for the OpenStack Stable Branch test reports.

Reply: openstack-dev@lists.openstack.org 
Date: June 21, 2016 at 01:13:47
To: openstack-stable-ma...@lists.openstack.org

Subject:  [Openstack-stable-maint] Stable check of openstack/manila failed

> http://logs.openstack.org/periodic-stable/periodic-manila-python27-liberty/e7a177d/

Manila's liberty branch is failing due to the fact that oslo is not
capped on stable/liberty. The lack of a cap (as we discussed in
yesterday's meeting) is not just affecting Manila though.

--
Ian Cordasco

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

Re: [openstack-dev] Version header for OpenStack microversion support

[Monty Taylor]

On 06/21/2016 12:59 AM, Clint Byrum wrote:
> Excerpts from Edward Leafe's message of 2016-06-20 20:41:56 -0500:
>> On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:
>>
>>> Whatever API version is used behind the compute API is none of the user's
>>> business.
>>
>> Actually, yeah, it is.
>>
>> If I write an app or a tool that expects to send information in a certain 
>> format, and receive responses in a certain format, I don't want that to 
>> change when the cloud operator upgrades their system. I only want things to 
>> change when I specifically request that they change by specifying a new 
>> microversion.
>>
> 
> The things I get back in the compute API are the purview of the compute
> API, and nothing else.
> 
> Before we go too far down this road, is there actually an example of
> one API providing a proxy to another directly? If so, is it something
> we think is actually a good idea?
> 
> Because otherwise, the API I'm talking to needs to be clear about what
> it does and does not emit and/or accept. That contract would just be
> the microversion of the API I'm talking to.

I'll agree with Clint here, and give an example.

When I talk to Nova and get a detail record for a server, Nova talks to
Neutron and puts data that it receives into the addresses dict on the
server record. This is not the neutron data structure. In fact, it has
some information from the Network and some from the Port (it would be
helpful if it had _more_ info, but that's not the point here)

In any case, the data structure returned by Nova is not related in any
way to the version of Neutron that nova is talking to - nor should it be.

Here's an example (in yaml not json)

  addresses:
GATEWAY_NET:
- OS-EXT-IPS-MAC:mac_addr: fa:16:3e:ea:d8:0d
  OS-EXT-IPS:type: fixed
  addr: 172.99.106.178
  version: 4

If you want a neutron record, you'll talk to neutron.

__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[Michael Krotscheck]

[Non-specific to nova]

I generated a list of which frameworks were in use in Mitaka - it's at the
top of the blog post I reference below, so you don't have to dig into it
too much to get the data.

TL/DR:
- falcon: 4 projects
- custom + routes: 12 projects
- pecan: 12 projects
- flask: 2 projects
- web.py: 1 project

With that in mind, I caution everyone not to surrender to the bandwagon
logical fallacy. "That's what we've always done" or "That's what most
people are doing" isn't actually an argument pro or con, it's merely
supporting the status quo because doing anything else would be hard (tm).

I think we can all agree on the following:
- Consistency is good. We need to pick one approach.
- Offloading support overhead onto a common codebase is better.

As for what the choice should be, this should be a thing the Architecture
WG makes a recommendation on, and with endorsement from the TC, would
actually be worthwhile for other projects to migrate to.

https://krotscheck.net/2016/03/25/we-need-an-consistent-openstack.html

Michael
__
OpenStack Development Mailing List (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] X509 Management

[Adam Young]

When deploying the overcloud with TLS, the current "no additional 
technology" approach is to use opensssl and self signed.  While this 
works for a Proof of concept, it does not make sense if the users need 
to access the resources from remote systems.


It seems to me that the undercloud, as the system of record for 
deploying the overcloud, should be responsible for centralizing the 
signing of certificates.


When deploying a service, the puppet module sure trigger a getcert call, 
which registers the cert with  Certmonger.  Certmonger is responsible 
for making sure the CSR gets to the signing authority, and fetching the 
cert.


Certmonger works via helper apps.  While there is currently a "self 
signed" helper, this does not do much if two or more systems need to 
have the same CA sign their certs.


It would be fairly simple to write a certmonger helper program that 
sends a CSR from a controller or compute node to the undercloud, has the 
Heat instance on the undercloud validate the request, and then pass it 
on to the signing application.


I'm not really too clear on how callbacks are  done from the 
os-collect-config processes to Heat, but I am guessing it is some form 
of Rest API that could be reused for this work flow?



I would see this as the lowest level of deployment.  We can make use of 
Anchor or Dogtag helper apps already.  This might also prove a decent 
middleground for people that need an automated approach to tie in with a 
third party CA, where they need some confirmation from the deployment 
process that the data in the CSR is valid and should be signed.


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

Re: [openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

[Martin André]

On Tue, Jun 21, 2016 at 12:41 PM, Tomas Sedovic  wrote:
> On 06/20/2016 06:37 PM, Joe Talerico wrote:
>>
>> Hello - It would seem there is a little bit of overlap with TripleO
>> validations ( clapper validations ) and Browbeat *Checks*. I would
>> like to see these two come together, and I wanted to get some feedback
>> on this.
>>
>> For reference here are the Browbeat checks :
>> https://github.com/openstack/browbeat/tree/master/ansible/check
>>
>> We check for common deployment mistakes, possible deployment
>> performance issues and some bugs that could impact the scale and
>> performance of your cloud... At the end we build a report of found
>> issues with the cloud, like :
>>
>> https://github.com/openstack/browbeat/blob/master/ansible/check/browbeat-example-bug_report.log
>>
>> We eventually wanted to take these findings and push them to
>> ElasticSearch as metadata for our result data (just so we would be
>> aware of any BZs or possibly missed tuning).
>>
>> Anyhoo, I just would like to get feedback on consolidating these
>> checks into TripleO Validations if that makes sense. If this does make
>> sense, who could I work with to see that this happens?
>
>
> Hey!
>
> I'd love to have a single place for all the validations if it's at all
> possible.
>
> Our repos are structured a little differently, but I hope we can come up
> with a solution that works for both uses.
>
> The primary idea behind the tripleo-validations (née Clapper) repo is to
> have have checks in the various stages of the deployment to find potential
> hardware issues or incorrect configuration early.
>
> We want to have these run by the cli and the web ui automatically, which is
> why we opted for the one validation (playbook) with extra metadata per file
> approach.
>
> There are two people working on these right now: myself and Martin André.
> We're in #tripleo (mandre & shadower). Feel free to talk to either of us,
> though I suspect I may have more time for this.
>
> We're both in the CE(S)T so there should be some overlap for realtime chat.

This is great! There's indeed a lot of overlap between browbreat
checks and tripleo-validations, and yeah, I think it makes perfect
sense to try to consolidate the tripleo-validations. You'll notice the
tripleo-validations repo is currently empty; we're starting from a
clean slate and haven't yet imported any of the the existing clapper
validations so now is actually a good time to discuss what you want to
see in the repo.

There will be a mistral workflow [1] that runs the validations (or
groups of validations). We can imagine an action (or separate
workflow) that pushes the results to ElasticSearch, but that would
require you to run the validations through mistral. Alternatively, we
could probably build this mechanism directly in ansible by adding some
kind of hook.

Martin

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

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

[openstack-dev] [kolla] Need help from all core reviewers

[Steven Dake (stdake)]

Hey folks,

We have a spec under review for Kolla + Kubernetes, which has been cooking for 
6-8 weeks.  The specification may have some gaps, but it gives a solid feeling 
to me atleast the work is achievable.

Note specifications are point in time plans and are never revised in the 
repository.  We revise through the natural blueprint and bug processes we 
already have in place.  Please take a moment to add your +2 to Ryan's 
specification (or -1 if something is grossly wrong).  Remember there are no 
vetos on specifications.  Note the implementation train has left the station 
about 4 weeks ago, so its pointless to try to keep the spec and implementation 
exactly coordinated.  Lets just get the spec merged so folks understand what 
the general plan is.

Personally I think Ryan has done a fantastic job.  Some folks would just have 
given up by now :)

Remember, we need a majority to approve specifications.  Even if the 
specification isn't approved, the work will proceed so might as well approve it 
;)

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

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

Re: [openstack-dev] [all][oslo] pbr potential breaking change coming

[Doug Hellmann]

Excerpts from Ihar Hrachyshka's message of 2016-06-21 15:40:45 +0200:
> 
> > On 21 Jun 2016, at 15:01, Doug Hellmann  wrote:
> > 
> > A while back pbr had a feature that let projects pass "warnerror"
> > through to Sphinx during documentation builds, causing any warnings in
> > that build to be treated as an error and fail the build. This lets us
> > avoid things like links to places that don't exist in the docs, bad but
> > renderable rst, typos in directive or role names, etc.
> > 
> > Somewhat more recently, but still a while ago, that feature "broke"
> > with a Sphinx release that was not API compatible. Sachi King has
> > fixed this issue within pbr, and so the next release of pbr will
> > fix the broken behavior and start correctly passing warnerror again.
> > That may result in doc builds breaking where they didn't before.
> > 
> > The short-term solution is to turn of warnerrors (look in your
> > setup.cfg), then fix the issues and turn it back on. Or you could
> > preemptively fix any existing warnings in your doc builds before the
> > release, but it's simple enough to turn off the feature if there isn't
> > time.
> 
> Thanks a lot for the heads-up. I pushed the following patch for neutron: 
> https://review.openstack.org/332145
> 
> I don’t fix warnings that may be currently in the tree. I will do it once we 
> have a new pbr release: even if I would fix warnings we may have now, it 
> wouldn’t give any guarantee to us that nothing would sneak into the tree 
> after my fix. So I prefer just wait for new pbr and then fix it all in one go.
> 
> Ihar

That approach makes sense.

Doug

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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Clint Byrum]

Excerpts from Chris Dent's message of 2016-06-21 09:25:44 +0100:
> On Mon, 20 Jun 2016, Doug Wiegley wrote:
> 
> > So, it sounds like you’ve just described the job of the TC. And they
> > have so far refused to define OpenStack, leading to a series of
> > derivative decisions that seem … inconsistent over time.
> 
> Thanks for writing down what I was thinking. I agree that OpenStack
> needs some architectural vision, direction, leadership, call it what
> you will. Every time I've voted for the _Technical_ Committee that
> leadership is what I've wanted my vote to be creating.
> 

I think that's still part of it. The difference is that the TC is using
their expertise to resolve conflict and ratify decisions, while a working
group is creating a source of data and taking actions that hopefully
prevent the conflict from ever arising.

> It may be that an architecture working group can provide some
> guidance that people will find useful. Against the odds I think
> those of us in the API-WG have actually managed to have a positive
> influence. We've not shaken things down to the foundations from
> which a great a glorious future may be born -- a lot of compromises
> have been made and not everybody wants to play along -- but things
> are going in the right direction, for some people, in some projects.
> Maybe a similar thing can happen with architecture.
> 

I definitely saw what was happening with the API-WG and wanted to have a
similar effect on the design process.

> However, I worry deeply that it could become astronauts with finger
> paints. In the API working group at least we have the HTTP RFCs as
> foundational sources of authority to guide us. In something so
> fraught with opinion what are the sources of authority?
> 
> I was pointed at this a while ago
> 
>  https://wiki.openstack.org/wiki/BasicDesignTenets
> 
> It's full of lots of great rules that are frequently broken.
> 


This is a great point Chris. I definitely think we need to have some
authority to fall back on. The link above is a great start. I'd like to
invite others to think on that and share their sources of authority for
distributed system design.

__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[Clint Byrum]

Excerpts from Sean Dague's message of 2016-06-21 08:00:50 -0400:
> On 06/21/2016 07:39 AM, Jay Pipes wrote:
> > On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
> >> Le 21/06/2016 10:04, Chris Dent a écrit :
> >>> On Mon, 20 Jun 2016, Jay Pipes wrote:
> >>>
>  Flask seems to be the most widely used and known WSGI framework so
>  for consistency's sake, I'm recommending we just use it and not rock
>  this boat. There are more important things to get hung up on than
>  this battle right now.
> >>>
> >>> That seems perfectly reasonable. My main goal in starting the
> >>> discussion was to ensure that we reach some kind of consensus,
> >>> whatever it might be[1]. It won't be too much of an ordeal to
> >>> turn the existing pure WSGI stuff into Flask stuff.
> >>>
> >>> From my standpoint doing the initial development in straight WSGI
> >>> was a win as it allowed for a lot of clarity from the inside out.
> >>> Now that that development has shown the shape of the API we can
> >>> do what we need to do to make it clear from outside in.
> >>>
> >>> Next question: There's some support for not using Paste and
> >>> paste.ini. Is anyone opposed to that?
> >>>
> >>
> >> Given Flask is not something we support yet in Nova, could we discuss on
> >> that during either a Nova meeting, or maybe wait for the midcycle ?
> > 
> > I really don't want to wait for the mid-cycle. Happy to discuss in the
> > Nova meeting, but my preference is to have Chris just modify his patch
> > series to use Flask now and review it.
> > 
> >> To be honest, Chris and you were saying that you don't like Flask, and
> >> I'm a bit agreeing with you. Why now it's a good possibility ?
> > 
> > Because Doug persuaded me that the benefits of being consistent with
> > what the community is using outweigh my (and Chris') personal misgivings
> > about the particular framework.
> 
> Just to be clear
> 
> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
> 
> Flask is used by 2 (relatively new) projects in OpenStack
> 
> If we look at the iaas base layer:
> 
> Keystone - custom WSGI with Routes / Paste
> Glance - WSME + Routes / Paste
> Cinder - custom WSGI with Routes / Paste
> Neutron - pecan + Routes / Paste
> Nova - custom WSGI with Routes / Paste
> 

When I see "custom WSGI" I have a few thoughts:

* custom == special snowflake. But REST API's aren't exactly novel.

* If using a framework means not writing or cargo culting any custom
WSGI code, that seems like a win for maintainability from the get go.

* If using a framework means handling errors more consistently, that
seems like a win for operators.

* I don't have a grasp on how much custom WSGI code is actually
involved. That would help us all evaluate the meaning of the statements
above (both yours, and mine).

__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[Clint Byrum]

Excerpts from Sean Dague's message of 2016-06-21 09:10:00 -0400:
> The amount of wsgi glue above Routes / Paste is pretty minimal (after
> you get rid of all the extensions facilities).
> 
> Templating and Session handling are things we don't need. We're not a
> webapp, we're a REST service. Saying that using a web app framework is
> better than a little bit of wsgi glue seems weird to me.
> 

Actually we do have sessions. We just call them "tokens".

__
OpenStack Development Mailing List (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] Does nova-compute interact with nova Db?

[KHAN, RAO ADNAN]

I want to collect an *extra_resource* info from compute node(s) and add it in 
to the compute_nodes table. I like to understand how nova-compute interacts 
with DB currently.

Thanks,

Rao Adnan Khan
AT Integrated Cloud (AIC) Development | SE
Software Development & Engineering (SD)
Emai: rk2...@att.com
Cell phone: 972-342-5638

RESTRICTED - PROPRIETARY INFORMATION
This email is the property of AT and intended solely for the use of the 
addressee. If you have reason to believe you have received this in error, 
please delete this immediately; any other use, retention, dissemination, 
copying or printing of this email 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] [all] Proposal: Architecture Working Group

[Zane Bitter]

On 20/06/16 19:27, Clint Byrum wrote:

Excerpts from Doug Wiegley's message of 2016-06-20 10:40:56 -0600:

So, it sounds like you’ve just described the job of the TC.


It may sound like that, but the TC have repeatedly (and perhaps wisely) 
disclaimed that as part of their job. So any attempt to fill in this 
glaring gap in OpenStack (i.e. to attempt to design at a higher level 
than an individual project) should be welcomed with open arms IMHO. 
Nobody benefits when every project team is on their own to make 
architectural decisions in a vacuum, which is too often the case now.



And they have so far refused to define OpenStack, leading to a series of 
derivative decisions that seem … inconsistent over time.

How is this body going to be different?

How will it have any teeth, and not just end up with the standard entrenched 
projects ignoring it?



Hi Doug, thanks for your candid reply. I understand that there is a
concern and I want to address it. However, I feel like answering this
directly will start this working group out on the wrong foot.

We shouldn't need teeth. This isn't an adversarial working group that
will be challenging engineers any more than an architect of a building
challenges the builders while they work. An architect that ignores their
engineers is not going to complete many projects. Of course, engineers
may disagree on the cost of an architectural decision. But to disagree,
first we need to actually _make_ a decision on a design.

The goal of this group would be to provide a detailed architecture and
plans for the way the system should work and fit together as a whole. Like
any complex system, during implementation, things that architects weren't
aware of come to light. Something that seems simple turns out to be
complex. Something that seemed absolutely necessary can be factored out.

Nobody is suggesting designing OpenStack from the ground up, just that
where there isn't an agreed upon design, let's write down how the system
works now, and then make a design and a plan to actually improve it.

Engineers have no effective place to turn to right now when there is
a lack of design. The TC could of course do it, but what I want to do
is have a more open and free-flowing group that are laser focused on
providing support for the design of the system. I want to work out with
the community at large how we add weight to the designs we choose, and
one good option is for the Architecture Working Group to make proposals
to the openstack-specs repo, which the TC would ultimately approve.
That's not a new process, we already have it:

http://docs.openstack.org/project-team-guide/cross-project.html

I'm just suggesting a group that actually _focuses_ on the design
aspects of that process.

Without this, we are designing in real time and taking the shortest path
to achieve short term goals. This has positive and negative effects. I
think we've reached a point in OpenStack's evolution where the positive
effects of that are mostly realized, and now we should work to pay
down some of the negative effects by adopting some designs and beginning
refactoring of the system. It's not a fast process, so the longer we wait,
the longer we pay interest on that debt.


I can't +1 this enough. Thanks Clint for kicking off this initiative.

cheers,
Zane.


__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[David Stanek]

On Tue, Jun 21, 2016 at 08:00:50AM -0400, Sean Dague wrote:
> 
> Keystone - custom WSGI with Routes / Paste
>

Keystone is moving toward Flask. I have an experimental patch that
moves us in that direction. I'm in the process to rebasing and
fixing it up since it's wildly out of date.

-- David

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

Re: [openstack-dev] [all][oslo] pbr potential breaking change coming

[Ihar Hrachyshka]

> On 21 Jun 2016, at 15:01, Doug Hellmann  wrote:
> 
> A while back pbr had a feature that let projects pass "warnerror"
> through to Sphinx during documentation builds, causing any warnings in
> that build to be treated as an error and fail the build. This lets us
> avoid things like links to places that don't exist in the docs, bad but
> renderable rst, typos in directive or role names, etc.
> 
> Somewhat more recently, but still a while ago, that feature "broke"
> with a Sphinx release that was not API compatible. Sachi King has
> fixed this issue within pbr, and so the next release of pbr will
> fix the broken behavior and start correctly passing warnerror again.
> That may result in doc builds breaking where they didn't before.
> 
> The short-term solution is to turn of warnerrors (look in your
> setup.cfg), then fix the issues and turn it back on. Or you could
> preemptively fix any existing warnings in your doc builds before the
> release, but it's simple enough to turn off the feature if there isn't
> time.

Thanks a lot for the heads-up. I pushed the following patch for neutron: 
https://review.openstack.org/332145

I don’t fix warnings that may be currently in the tree. I will do it once we 
have a new pbr release: even if I would fix warnings we may have now, it 
wouldn’t give any guarantee to us that nothing would sneak into the tree after 
my fix. So I prefer just wait for new pbr and then fix it all in one go.

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] [Neutron] IRC meeting for VLAN-aware VM's

[Bence Romsics]

Today there's no IRC meeting dedicated to the trunk port work. Most of
the discussion is going on in gerrit:

https://review.openstack.org/#/q/topic:bp/vlan-aware-vms+-status:abandoned

Or here in the mailing list. If you feel the need for it let us know
and we can easily revive it.

--
Bence

On Mon, Jun 20, 2016 at 7:42 PM, Tidwell, Ryan  wrote:
> At one point early during the Mitaka cycle we had a weekly IRC meeting on
> this topic going.  I got side-tracked by other work at the time and I
> stopped attending, so my apologies if these are still happening.  I’m
> wondering if it would be useful to get these going again if this is not
> currently happening.  Thoughts?
>
>
>
> -Ryan
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Hayes, Graham]

On 21/06/2016 13:04, Sean Dague wrote:
> On 06/21/2016 07:39 AM, Jay Pipes wrote:
>> On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
>>> Le 21/06/2016 10:04, Chris Dent a écrit :
 On Mon, 20 Jun 2016, Jay Pipes wrote:

> Flask seems to be the most widely used and known WSGI framework so
> for consistency's sake, I'm recommending we just use it and not rock
> this boat. There are more important things to get hung up on than
> this battle right now.

 That seems perfectly reasonable. My main goal in starting the
 discussion was to ensure that we reach some kind of consensus,
 whatever it might be[1]. It won't be too much of an ordeal to
 turn the existing pure WSGI stuff into Flask stuff.

 From my standpoint doing the initial development in straight WSGI
 was a win as it allowed for a lot of clarity from the inside out.
 Now that that development has shown the shape of the API we can
 do what we need to do to make it clear from outside in.

 Next question: There's some support for not using Paste and
 paste.ini. Is anyone opposed to that?

>>>
>>> Given Flask is not something we support yet in Nova, could we discuss on
>>> that during either a Nova meeting, or maybe wait for the midcycle ?
>>
>> I really don't want to wait for the mid-cycle. Happy to discuss in the
>> Nova meeting, but my preference is to have Chris just modify his patch
>> series to use Flask now and review it.
>>
>>> To be honest, Chris and you were saying that you don't like Flask, and
>>> I'm a bit agreeing with you. Why now it's a good possibility ?
>>
>> Because Doug persuaded me that the benefits of being consistent with
>> what the community is using outweigh my (and Chris') personal misgivings
>> about the particular framework.
>
> Just to be clear
>
> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
>
> Flask is used by 2 (relatively new) projects in OpenStack

http://codesearch.openstack.org/?q=Flask=nope=requirements.txt=

Flask is used by a few projects.

>
> If we look at the iaas base layer:
>
> Keystone - custom WSGI with Routes / Paste
> Glance - WSME + Routes / Paste
> Cinder - custom WSGI with Routes / Paste
> Neutron - pecan + Routes / Paste
> Nova - custom WSGI with Routes / Paste
>
> I honestly don't think raw WSGI is a bad choice here. People are going
> to be pretty familiar with it in related projects at this level.
>
> Using selector instead of Routes makes things different for unclear
> gain. Sticking with Routes seems more prudent.
>
> Doing Flask is fine, but do it because we think that's the way things
> should be done, not because it's a common in our community, which it
> clearly is not. The common pattern is custom WSGI + Routes / Paste (at
> least at this layer in the stack).
>
>   -Sean
>


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

Re: [openstack-dev] [neutron][SFC]

[Alioune]

Hi all,
I 'm still trying to integrate sfc project with devstack using [1] but the
L2 agent is unable to chech status of br-int (see error bellow).
I think that the error is not due to OpenFlow version negociation since I
can execute the command "sudo ovs-ofctl dump-flows br-int -O OpenFlow13
table=23"

Someone knows how to solve this error ?
Regards,

Here are some information about my environement:
uname -r
3.16.0-30-generic

sudo ovs-vsctl --version
ovs-vsctl (Open vSwitch) 2.4.1
Compiled Jun 20 2016 14:56:46
DB Schema 7.12.1

sudo ovs-vsctl show
83a36bf9-e7fd-40cc-bd6e-fefb3119ff0c
Bridge br-int
Port br-int
Interface br-int
type: internal
Bridge br-ex
Port br-ex
Interface br-ex
type: internal
ovs_version: "2.4.1"

sudo ovs-ofctl dump-flows br-int -O OpenFlow13 table=23
OFPST_FLOW reply (OF1.3) (xid=0x2):

ERROR:

opt/stack/neutron/neutron/agent/linux/utils.py:101
2016-06-21 14:49:26.470 ERROR neutron.agent.linux.utils
[req-775e942c-237f-4872-9dd2-cf6cae7b34ed None None]
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
Exit code: 1
Stdin:
Stdout:
Stderr: ovs-ofctl: br-int is not a bridge or a socket

2016-06-21 14:49:26.485 ERROR
networking_sfc.services.sfc.common.ovs_ext_lib
[req-775e942c-237f-4872-9dd2-cf6cae7b34ed None None]
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
Exit code: 1
Stdin:
Stdout:
Stderr: ovs-ofctl: br-int is not a bridge or a socket

2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Traceback (most recent call
last):
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib   File
"/opt/stack/networking-sfc/networking_sfc/services/sfc/common/ovs_ext_lib.py",
line 125, in run_ofctl
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib
process_input=process_input)
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib   File
"/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib raise RuntimeError(m)
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib RuntimeError:
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Command: ['ovs-ofctl', '-O
openflow13', 'dump-flows', 'br-int', 'table=23']
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Exit code: 1
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Stdin:
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Stdout:
2016-06-21 14:49:26.485 TRACE
networking_sfc.services.sfc.common.ovs_ext_lib Stderr: ovs-ofctl: br-int is
not a bridge or a socket
2016-06-21 14:49:26.485 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
2016-06-21 14:49:26.485 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
2016-06-21 14:49:26.492 ERROR
networking_sfc.services.sfc.common.ovs_ext_lib
[req-775e942c-237f-4872-9dd2-cf6cae7b34ed None None] Unable to execute
['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23'].
2016-06-21 14:49:26.495 WARNING
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-775e942c-237f-4872-9dd2-cf6cae7b34ed None None] OVS is dead.
OVSNeutronAgent will keep running and checking OVS status periodically.
2016-06-21 14:49:26.498 DEBUG
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-775e942c-237f-4872-9dd2-cf6cae7b34ed None None] Agent rpc_loop -
iteration:1983 completed. Processed ports statistics: {'regular':
{'updated': 0, 'added': 0, 'removed': 0}}. Elapsed:0.050 from (pid=7331)
loop_count_and_wait
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1680

[1] https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

On 15 June 2016 at 16:22, Mohan Kumar  wrote:

> could you ping in IRC channel  handle #openstack-neutron  name : mohankumar
>
> On Wed, Jun 15, 2016 at 7:50 PM, Alioune  wrote:
>
>> Mohan,
>> Is it possible to configure the neutron-plugin-ovs-agent to use
>> OpenFlow13 ?
>>
>> Please could you tell me versions of your openstack environment ?
>>
>> Regards,
>>
>> On 15 June 2016 at 12:58, Alioune  wrote:
>>
>>> Sorry for not being clear,
>>> I juste have the same architecture like in your ONOS demo but I'm only
>>> using neutron without any SDN controller in backend.
>>>
>>> On Wednesday, 15 June 2016, Mohan Kumar 
>>> wrote:
>>>
 Alioune ,

 I suspect this could be OVS cleanup issue , you have to delete ovs
 bridge interfaces and manager before installing  ONOS  feature: , I
 recommend you  to follow below link to set ONOS  ML2 support.

 http://artifacts.opnfv.org/onosfw/brahmaputra/Brahmaputra_userguide/onosfw-userguide.html
 ( ONOSFW 

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Sean Dague]

On 06/21/2016 08:42 AM, Doug Hellmann wrote:
> Excerpts from Sean Dague's message of 2016-06-21 08:00:50 -0400:
>> On 06/21/2016 07:39 AM, Jay Pipes wrote:
>>> On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
 Le 21/06/2016 10:04, Chris Dent a écrit :
> On Mon, 20 Jun 2016, Jay Pipes wrote:
>
>> Flask seems to be the most widely used and known WSGI framework so
>> for consistency's sake, I'm recommending we just use it and not rock
>> this boat. There are more important things to get hung up on than
>> this battle right now.
>
> That seems perfectly reasonable. My main goal in starting the
> discussion was to ensure that we reach some kind of consensus,
> whatever it might be[1]. It won't be too much of an ordeal to
> turn the existing pure WSGI stuff into Flask stuff.
>
> From my standpoint doing the initial development in straight WSGI
> was a win as it allowed for a lot of clarity from the inside out.
> Now that that development has shown the shape of the API we can
> do what we need to do to make it clear from outside in.
>
> Next question: There's some support for not using Paste and
> paste.ini. Is anyone opposed to that?
>

 Given Flask is not something we support yet in Nova, could we discuss on
 that during either a Nova meeting, or maybe wait for the midcycle ?
>>>
>>> I really don't want to wait for the mid-cycle. Happy to discuss in the
>>> Nova meeting, but my preference is to have Chris just modify his patch
>>> series to use Flask now and review it.
>>>
 To be honest, Chris and you were saying that you don't like Flask, and
 I'm a bit agreeing with you. Why now it's a good possibility ?
>>>
>>> Because Doug persuaded me that the benefits of being consistent with
>>> what the community is using outweigh my (and Chris') personal misgivings
>>> about the particular framework.
>>
>> Just to be clear
>>
>> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
>>
>> Flask is used by 2 (relatively new) projects in OpenStack
>>
>> If we look at the iaas base layer:
>>
>> Keystone - custom WSGI with Routes / Paste
>> Glance - WSME + Routes / Paste
>> Cinder - custom WSGI with Routes / Paste
>> Neutron - pecan + Routes / Paste
>> Nova - custom WSGI with Routes / Paste
>>
>> I honestly don't think raw WSGI is a bad choice here. People are going
>> to be pretty familiar with it in related projects at this level.
>>
>> Using selector instead of Routes makes things different for unclear
>> gain. Sticking with Routes seems more prudent.
>>
>> Doing Flask is fine, but do it because we think that's the way things
>> should be done, not because it's a common in our community, which it
>> clearly is not. The common pattern is custom WSGI + Routes / Paste (at
>> least at this layer in the stack).
>>
>> -Sean
>>
> 
> As I told Jay, I don't care which specific framework is used. I
> care about the fact that while we're trying to get other projects
> to standardize on frameworks supported upstream so we have tools
> with good documentation and we carry less code directly in this
> community, we have consistently had a hard time convincing the nova
> team to choose one instead of building one.
> 
> Jay didn't like the object-dispatch model used in Pecan, so I pointed
> out that Flask is also in use elsewhere. The fact that Flask is not yet
> widespread indicates that project teams are not needlessly rewriting
> existing API services, rather than lack of acceptance. If you don't like
> either Flaks or Pecan, look at Pyramid or Pylons or one of the others.
> But please stop building new frameworks that make your project so
> completely different from everything else in the Python ecosystem.

The amount of wsgi glue above Routes / Paste is pretty minimal (after
you get rid of all the extensions facilities).

Templating and Session handling are things we don't need. We're not a
webapp, we're a REST service. Saying that using a web app framework is
better than a little bit of wsgi glue seems weird to me.

Falcon looks like the only thing out there which is really stripped down
to this little bit of glue layer. So if the answer is "must use
framework" that seems like the right answer. However, Routes + Paste is
really the framework we are using broadly in OpenStack. And a lot of the
common middleware assume that.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [Cinder][Tempest][Infra] Cinder team seeks test/tempest/infra experts

[D'Angelo, Scott]

The Cinder team has begun a test working group[1] with the goal of improving 
coverage and quality.

We meet Weekly[2] at 1500 UTC in #openstack-cinder and would welcome anyone 
interested in providing expertise in Tempest/Infra/QA.


Our Cinder team contributors have a smattering of knowledge and experience with 
Tempest and the Infra changes required, but we find we've gaps . We've embarked 
on adding tests for multi-backend scenarios and are especially interested in 
multi-node Cinder testing (and Infra changes) and Microversion testing. Please 
join us if interested, and/or ping in the #openstack-cinder room.


Thanks!

Scott DAngelo (scottda)


[1] 
https://etherpad.openstack.org/p/Cinder-testing

[2] https://wiki.openstack.org/wiki/CinderMeetings#Weekly_Cinder_Test_meeting

__
OpenStack Development Mailing List (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] [all][oslo] pbr potential breaking change coming

[Doug Hellmann]

A while back pbr had a feature that let projects pass "warnerror"
through to Sphinx during documentation builds, causing any warnings in
that build to be treated as an error and fail the build. This lets us
avoid things like links to places that don't exist in the docs, bad but
renderable rst, typos in directive or role names, etc.

Somewhat more recently, but still a while ago, that feature "broke"
with a Sphinx release that was not API compatible. Sachi King has
fixed this issue within pbr, and so the next release of pbr will
fix the broken behavior and start correctly passing warnerror again.
That may result in doc builds breaking where they didn't before.

The short-term solution is to turn of warnerrors (look in your
setup.cfg), then fix the issues and turn it back on. Or you could
preemptively fix any existing warnings in your doc builds before the
release, but it's simple enough to turn off the feature if there isn't
time.

Josh, Sachi, & other Oslo folks, I think we should hold off on
releasing until next week to give folks time. Is that OK?

Doug

PS - Thanks, Sachi, I know that bug wasn't a ton of fun to fix!

__
OpenStack Development Mailing List (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] Deprecation and release notes

[Armando M.]

Hi Neutrinos,

I would like to remind you to be extra careful when handling the
deprecation of config options.

Do not forget to associate release notes when appropriate, or even bug
reports tagged with 'deprecation' to track the deprecation cycle. Alerting
operators/deployers/packagers of impeding changes to their configuration
files makes us more friendly to our users.

I have seen instances of neglects [1,2] on this front.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/330273/
[2] https://review.openstack.org/#/c/332018/
__
OpenStack Development Mailing List (not for 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] Action parameter missing in generated stonith fence manifests

[Sofer Athlan-Guyot]

Hi Devon,

Devon Mizelle  writes:

> Greetings,
>
> I was directed here from #puppet-openstack to submit an e-mail.

Well, the best way to have it done, would be to make bug in launchap[1]

If you don't have the an account or the time time let me know I will do
it for you, np.

The patch shouldn't be a problem, but the diff here misses some bits :)

Thanks,

[1] https://bugs.launchpad.net/puppet-pacemaker/+bugs

> Noted here, there is an 'action' parameter defined for fence_ifmib:
>
> https://github.com/openstack/puppet-pacemaker/blob/f62805f678f6fd8a260118279f6e0dbb05bff3d1/agent_generator/src_xml/fence_ifmib.xml#L83
>
> However, in the generated manifest here, it seems that the 'action'
> parameter is missing:
>
> https://github.com/openstack/puppet-pacemaker/blob/f62805f678f6fd8a260118279f6e0dbb05bff3d1/manifests/stonith/fence_ifmib.pp
>
> It looks like the 'action' parameter is missing in every fence_*
> manifest (and has never existed.) I need this available to me so that
> I can override the default action of fence_ifmib (which is 'reboot')
> and set it to 'off'.
>
> It looks like that in the agent_generator.rb script, action is being
> specifically ignored in addition to 'help' and 'version' parameters.
> I've attached a quick plain-text patch. I don't think this is the
> norm, but considering that its such a small one word change I'm hoping
> it would be OK.
>
> Thanks for your time and for a wonderful project,
> Devon
>
> diff --git a/agent_generator/agent_generator.rb
> b/agent_generator/agent_generator.rb
> index 9c1ab0a..171ca50 100755
> --- a/agent_generator/agent_generator.rb
> +++ b/agent_generator/agent_generator.rb
> @@ -40,7 +40,7 @@ class FencingMetadataParser
>param['default'] = REXML::XPath.match(p, 
> 'string(./content/@default)')[0]
>param['description'] = REXML::XPath.match(p, 'string(./shortdesc)')[0]
>## remove parameters that are not usable during automatic execution
> -  @params.push(param) unless %w(help version
> action).include?(param['name'])
> +  @params.push(param) unless %w(help version).include?(param['name'])
>  }
>  @params
>end
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Sofer Athlan-Guyot

__
OpenStack Development Mailing List (not for 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] Intermittent failures on unit tests

[Armando M.]

On 21 June 2016 at 08:41, Armando M.  wrote:

> Neutrinos,
>
> There's been a number of intermittent failures induced by the DNS
> integration code that popped up lately. One has been reported in [1],
> another showed up in [2]. I am in the progress of digging deeper to see
> what's going on, but if someone knows or working on the issue, please let
> us know.
>
> Also, please do not recheck blindly hoping the issue goes away.
>

I spoke with Ihar on IRC and it turns out it may (or may not be) that the
issue related to [2] is induced by change [3] or even [4], see [5] for more
details.

Cheers,
Armando


> Thanks,
> Armando
>
> [1] https://bugs.launchpad.net/neutron/+bug/1593647
> [2] https://bugs.launchpad.net/neutron/+bug/1594796
>

[3] https://review.openstack.org/#/c/327413/
[4] https://review.openstack.org/#/c/330273/
[5] http://paste.openstack.org/show/520931/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][monasca][requirements] Kafka 1.x for Oslo.Messaging and Monasca

[Davanum Srinivas]

Roland Hochmuth, Joe Keen,

The oslo.messaging folks have been trying off and on again [1] to get
to python-kafka 1.x. Right now they are waiting on the Monasca team as
we reverted python-kafka 1.x in [2] for the Monasca Team.

I still don't see a review for adding Monasca to projects.txt which is
concerning. Is there work being done to get to that point?

The oslo.messaging team will file a review to update to 1.x again when
they are ready, when that happens, we will end up breaking Monasca CI
jobs again. Unless of course Monasca is in projects.txt by that time
and adhering to requirements.

If both oslo.messaging and Monasca are under requirements, we still
need a way to move forward together. So please treat this email thread
as an opportunity to talk to each other :) Which should have started
ideally when we did [2]

Thanks,
Dims

[1] 
https://review.openstack.org/#/q/kafka+project:openstack/oslo.messaging+NOT+is:merged+NOT+is:abandoned
[2] https://review.openstack.org/#/c/316259/

-- 
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] [all][tc] Require a level playing field for OpenStack projects

[Zane Bitter]

On 20/06/16 18:50, Jeremy Stanley wrote:

On 2016-06-20 18:43:44 +0200 (+0200), Zane Bitter wrote:

The binaries are free-as-in-beer - IIUC you can't redistribute them. The
source code, of course, remains free-as-in-speech as it has always been.
(It's easy to forget the distinction when you work in Python all day and
there are no binaries, but it's the source code that counts.) And of course
there are freely-distributable binaries built from that source available in
the form of CentOS.

[...]

Not to go too far down this rabbit hole, but as a
long-time-away-from-Red-Hat user my (possibly quite outdated)
experience was that RHEL included some non-free/proprietary software
distributed alongside other free-as-in-speech software. If this is
still true, it would be a significant mischaracterization to claim
that the "source code" for RHEL as a whole is consistently free.


That isn't my understanding, but it's hard to give a definitive answer 
without knowing what kinds of non-free software you're referring to 
(since I know there have been fierce disagreements even e.g. within 
Debian on topics like firmware blobs). Certainly if anything in 
https://fedoraproject.org/wiki/Licensing:Main bothers you then you'll 
probably be unhappy.


There *is* a "Supplementary" channel that includes non-free software - 
IBM Java (ikr? apparently that's a real thing), certain CJK fonts... 
that kind of random, obscure stuff - but you have to download a separate 
DVD and/or enable a separate yum repo that is disabled by default. 
You'll never need to go near it.


But e.g. if a user wants to install the proprietary nVidia driver, RH 
tells them to go download it from nVidia.[1] It's not shipped in RHEL or 
even the Supplementary channel.


cheers,
Zane.

[1] https://access.redhat.com/solutions/5258 (paywalled, sorry):


If
_all_ software provided by RHEL is also now included under free and
open licenses, then I'm thrilled and may be more inclined to give it
a try again in the future.




__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-06-21 08:00:50 -0400:
> On 06/21/2016 07:39 AM, Jay Pipes wrote:
> > On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
> >> Le 21/06/2016 10:04, Chris Dent a écrit :
> >>> On Mon, 20 Jun 2016, Jay Pipes wrote:
> >>>
>  Flask seems to be the most widely used and known WSGI framework so
>  for consistency's sake, I'm recommending we just use it and not rock
>  this boat. There are more important things to get hung up on than
>  this battle right now.
> >>>
> >>> That seems perfectly reasonable. My main goal in starting the
> >>> discussion was to ensure that we reach some kind of consensus,
> >>> whatever it might be[1]. It won't be too much of an ordeal to
> >>> turn the existing pure WSGI stuff into Flask stuff.
> >>>
> >>> From my standpoint doing the initial development in straight WSGI
> >>> was a win as it allowed for a lot of clarity from the inside out.
> >>> Now that that development has shown the shape of the API we can
> >>> do what we need to do to make it clear from outside in.
> >>>
> >>> Next question: There's some support for not using Paste and
> >>> paste.ini. Is anyone opposed to that?
> >>>
> >>
> >> Given Flask is not something we support yet in Nova, could we discuss on
> >> that during either a Nova meeting, or maybe wait for the midcycle ?
> > 
> > I really don't want to wait for the mid-cycle. Happy to discuss in the
> > Nova meeting, but my preference is to have Chris just modify his patch
> > series to use Flask now and review it.
> > 
> >> To be honest, Chris and you were saying that you don't like Flask, and
> >> I'm a bit agreeing with you. Why now it's a good possibility ?
> > 
> > Because Doug persuaded me that the benefits of being consistent with
> > what the community is using outweigh my (and Chris') personal misgivings
> > about the particular framework.
> 
> Just to be clear
> 
> http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==
> 
> Flask is used by 2 (relatively new) projects in OpenStack
> 
> If we look at the iaas base layer:
> 
> Keystone - custom WSGI with Routes / Paste
> Glance - WSME + Routes / Paste
> Cinder - custom WSGI with Routes / Paste
> Neutron - pecan + Routes / Paste
> Nova - custom WSGI with Routes / Paste
> 
> I honestly don't think raw WSGI is a bad choice here. People are going
> to be pretty familiar with it in related projects at this level.
> 
> Using selector instead of Routes makes things different for unclear
> gain. Sticking with Routes seems more prudent.
> 
> Doing Flask is fine, but do it because we think that's the way things
> should be done, not because it's a common in our community, which it
> clearly is not. The common pattern is custom WSGI + Routes / Paste (at
> least at this layer in the stack).
> 
> -Sean
> 

As I told Jay, I don't care which specific framework is used. I
care about the fact that while we're trying to get other projects
to standardize on frameworks supported upstream so we have tools
with good documentation and we carry less code directly in this
community, we have consistently had a hard time convincing the nova
team to choose one instead of building one.

Jay didn't like the object-dispatch model used in Pecan, so I pointed
out that Flask is also in use elsewhere. The fact that Flask is not yet
widespread indicates that project teams are not needlessly rewriting
existing API services, rather than lack of acceptance. If you don't like
either Flaks or Pecan, look at Pyramid or Pylons or one of the others.
But please stop building new frameworks that make your project so
completely different from everything else in the Python ecosystem.

Doug

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

Re: [openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.

[Markus Zoeller]

A reminder that this will happen in ~2 weeks.

Please note that you can spare bug reports if you leave a comment there
which says one of these (case-sensitive flags):
* CONFIRMED FOR: NEWTON
* CONFIRMED FOR: MITAKA
* CONFIRMED FOR: LIBERTY

On 23.05.2016 13:02, Markus Zoeller wrote:
> TL;DR: Automatic closing of 185 bug reports which are older than 18
> months in the week R-13. Skipping specific bug reports is possible. A
> bug report comment explains the reasons.
> 
> 
> I'd like to get rid of more clutter in our bug list to make it more
> comprehensible by a human being. For this, I'm targeting our ~185 bug
> reports which were reported 18 months ago and still aren't in progress.
> That's around 37% of open bug reports which aren't in progress. This
> post is about *how* and *when* I do it. If you have very strong reasons
> to *not* do it, let me hear them.
> 
> When
> 
> I plan to do it in the week after the non-priority feature freeze.
> That's week R-13, at the beginning of July. Until this date you can
> comment on bug reports so they get spared from this cleanup (see below).
> Beginning from R-13 until R-5 (Newton-3 milestone), we should have
> enough time to gain some overview of the rest.
> 
> I also think it makes sense to make this a repeated effort, maybe after
> each milestone/release or monthly or daily.
> 
> How
> ---
> The bug reports which will be affected are:
> * in status: [new, confirmed, triaged]
> * AND without assignee
> * AND created at: > 18 months
> A preview of them can be found at [1].
> 
> You can spare bug reports if you leave a comment there which says
> one of these (case-sensitive flags):
> * CONFIRMED FOR: NEWTON
> * CONFIRMED FOR: MITAKA
> * CONFIRMED FOR: LIBERTY
> 
> The expired bug report will have:
> * status: won't fix
> * assignee: none
> * importance: undecided
> * a new comment which explains *why* this was done
> 
> The comment the expired bug reports will get:
> This is an automated cleanup. This bug report got closed because
> it is older than 18 months and there is no open code change to
> fix this. After this time it is unlikely that the circumstances
> which lead to the observed issue can be reproduced.
> If you can reproduce it, please:
> * reopen the bug report
> * AND leave a comment "CONFIRMED FOR: "
>   Only still supported release names are valid.
>   valid example: CONFIRMED FOR: LIBERTY
>   invalid example: CONFIRMED FOR: KILO
> * AND add the steps to reproduce the issue (if applicable)
> 
> 
> Let me know if you think this comment gives enough information how to
> handle this situation.
> 
> 
> References:
> [1] http://45.55.105.55:8082/bugs-dashboard.html#tabExpired
> 


-- 
Regards, Markus Zoeller (markus_z)


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

[openstack-dev] [Neutron] Intermittent failures on unit tests

[Armando M.]

Neutrinos,

There's been a number of intermittent failures induced by the DNS
integration code that popped up lately. One has been reported in [1],
another showed up in [2]. I am in the progress of digging deeper to see
what's going on, but if someone knows or working on the issue, please let
us know.

Also, please do not recheck blindly hoping the issue goes away.

Thanks,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1593647
[2] https://bugs.launchpad.net/neutron/+bug/1594796
__
OpenStack Development Mailing List (not for 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] Virtuozzo (Compute) CI is incorrectly patching for resize support

[Maxim Nestratov]

15.06.2016 0:51, Matt Riedemann пишет:

It was pointed out today in IRC that the Virtuozzo CI has been failing 
on this change for the libvirt imagebackend refactor:


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

Diana was having a hard time sorting out the line numbers in the stack 
trace though from the logs, because they didn't exist in her series.


Long story short, that's because the job checks to see if the change 
is the change that adds resize support for virtuozzo:


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

And if not, it fetches that change:

23:48:46 2016-06-10 23:48:58.863 | + cd /opt/stack/new/nova
23:48:46 2016-06-10 23:48:58.872 | + [[ 282580 -ne 182257 ]]
23:48:46 2016-06-10 23:48:58.875 | + git fetch 
https://review.openstack.org/p/openstack/nova refs/changes/57/182257/37
23:48:59 2016-06-10 23:49:11.357 | From 
https://review.openstack.org/p/openstack/nova
23:48:59 2016-06-10 23:49:11.359 |  * branch refs/changes/57/182257/37 
-> FETCH_HEAD

23:48:59 2016-06-10 23:49:11.366 | + git cherry-pick FETCH_HEAD
23:48:59 2016-06-10 23:49:11.689 | [detached HEAD 44b6772] libvirt: 
virtuozzo instance resize support


It's not valid to patch Nova for your CI when testing other changes, 
it breaks the whole point of CI testing if you have to patch things in 
it that aren't in the actual dependency change or repo - because when 
it fails, like in this case, one doesn't know if it's their actual 
change that's broken or the patch in the CI job.


I'm assuming this was done because I asked for the Virtuozzo CI to run 
the resize tests in tempest against 
https://review.openstack.org/#/c/182257/ - which it is, but that 
didn't mean also do it for all other changes in Nova. The CI job 
should conditionally enable those tests when testing change 182257 but 
not anything else until that's merged.


As a side note, the job isn't fetching the latest patch set of the 
resize change anyway, at least not as of last week, it's fetching 
patch set 37 but 39 is the latest.


Anyway, this isn't meant to shame, but to inform and correct. No one 
from the Virtuozzo team was in the nova IRC channel when we discovered 
this, so I needed to get it into the dev list.


But please get this fixed ASAP since it's invalidating the Virtuozzo 
CI results.




Just to update everyone interested. Finally we re-enabled our CI. Now 
it's fixed the way described above.


Maxim

__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[Sylvain Bauza]

Le 21/06/2016 14:00, Sean Dague a écrit :

On 06/21/2016 07:39 AM, Jay Pipes wrote:

On 06/21/2016 05:43 AM, Sylvain Bauza wrote:

Le 21/06/2016 10:04, Chris Dent a écrit :

On Mon, 20 Jun 2016, Jay Pipes wrote:


Flask seems to be the most widely used and known WSGI framework so
for consistency's sake, I'm recommending we just use it and not rock
this boat. There are more important things to get hung up on than
this battle right now.

That seems perfectly reasonable. My main goal in starting the
discussion was to ensure that we reach some kind of consensus,
whatever it might be[1]. It won't be too much of an ordeal to
turn the existing pure WSGI stuff into Flask stuff.

 From my standpoint doing the initial development in straight WSGI
was a win as it allowed for a lot of clarity from the inside out.
Now that that development has shown the shape of the API we can
do what we need to do to make it clear from outside in.

Next question: There's some support for not using Paste and
paste.ini. Is anyone opposed to that?


Given Flask is not something we support yet in Nova, could we discuss on
that during either a Nova meeting, or maybe wait for the midcycle ?

I really don't want to wait for the mid-cycle. Happy to discuss in the
Nova meeting, but my preference is to have Chris just modify his patch
series to use Flask now and review it.


To be honest, Chris and you were saying that you don't like Flask, and
I'm a bit agreeing with you. Why now it's a good possibility ?

Because Doug persuaded me that the benefits of being consistent with
what the community is using outweigh my (and Chris') personal misgivings
about the particular framework.

Just to be clear

http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==

Flask is used by 2 (relatively new) projects in OpenStack


TBC, even Blazar (ex. Climate reservation system) no longer uses Flask 
for its API v2 (Pecan+WSME), just for the legacy v1.




If we look at the iaas base layer:

Keystone - custom WSGI with Routes / Paste
Glance - WSME + Routes / Paste
Cinder - custom WSGI with Routes / Paste
Neutron - pecan + Routes / Paste
Nova - custom WSGI with Routes / Paste

I honestly don't think raw WSGI is a bad choice here. People are going
to be pretty familiar with it in related projects at this level.

Using selector instead of Routes makes things different for unclear
gain. Sticking with Routes seems more prudent.


I tend to agree with you here. Also, tbc, the placement API is still in 
the Nova tree so that's why I wonder why we should have a different WSGI 
router.




Doing Flask is fine, but do it because we think that's the way things
should be done, not because it's a common in our community, which it
clearly is not. The common pattern is custom WSGI + Routes / Paste (at
least at this layer in the stack).


++


-Sean




__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[Sean Dague]

On 06/21/2016 07:39 AM, Jay Pipes wrote:
> On 06/21/2016 05:43 AM, Sylvain Bauza wrote:
>> Le 21/06/2016 10:04, Chris Dent a écrit :
>>> On Mon, 20 Jun 2016, Jay Pipes wrote:
>>>
 Flask seems to be the most widely used and known WSGI framework so
 for consistency's sake, I'm recommending we just use it and not rock
 this boat. There are more important things to get hung up on than
 this battle right now.
>>>
>>> That seems perfectly reasonable. My main goal in starting the
>>> discussion was to ensure that we reach some kind of consensus,
>>> whatever it might be[1]. It won't be too much of an ordeal to
>>> turn the existing pure WSGI stuff into Flask stuff.
>>>
>>> From my standpoint doing the initial development in straight WSGI
>>> was a win as it allowed for a lot of clarity from the inside out.
>>> Now that that development has shown the shape of the API we can
>>> do what we need to do to make it clear from outside in.
>>>
>>> Next question: There's some support for not using Paste and
>>> paste.ini. Is anyone opposed to that?
>>>
>>
>> Given Flask is not something we support yet in Nova, could we discuss on
>> that during either a Nova meeting, or maybe wait for the midcycle ?
> 
> I really don't want to wait for the mid-cycle. Happy to discuss in the
> Nova meeting, but my preference is to have Chris just modify his patch
> series to use Flask now and review it.
> 
>> To be honest, Chris and you were saying that you don't like Flask, and
>> I'm a bit agreeing with you. Why now it's a good possibility ?
> 
> Because Doug persuaded me that the benefits of being consistent with
> what the community is using outweigh my (and Chris') personal misgivings
> about the particular framework.

Just to be clear

http://codesearch.openstack.org/?q=Flask%3E%3D0.10=nope==

Flask is used by 2 (relatively new) projects in OpenStack

If we look at the iaas base layer:

Keystone - custom WSGI with Routes / Paste
Glance - WSME + Routes / Paste
Cinder - custom WSGI with Routes / Paste
Neutron - pecan + Routes / Paste
Nova - custom WSGI with Routes / Paste

I honestly don't think raw WSGI is a bad choice here. People are going
to be pretty familiar with it in related projects at this level.

Using selector instead of Routes makes things different for unclear
gain. Sticking with Routes seems more prudent.

Doing Flask is fine, but do it because we think that's the way things
should be done, not because it's a common in our community, which it
clearly is not. The common pattern is custom WSGI + Routes / Paste (at
least at this layer in the stack).

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install

[Jay Pipes]

On 06/21/2016 12:37 AM, Andre Florath wrote:

Hi!

Before things getting said twice (looks that there is some
public interest here ;-) ):


:)


Can you please rerun and skip the partition part of
the loop device for fdisk -l?
E.g. instead of /dev/loop0p1 just /dev/loop0?
(This was my original intend but maybe not correctly
described.)


Got it. Here you go:

root@brix-1:/# fdisk -l /dev/loop0

Disk /dev/loop0: 10.7 GB, 10737418240 bytes
107 heads, 17 sectors/track, 11529 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xefd0e90b

  Device Boot  Start End  Blocks   Id  System
/dev/loop0p1   *   12097151910485759+  83  Linux

You'd mentioned in your previous private email to me that the start 
should be 2048. Clearly, it's 1 above. Is that an indication of a problem?



Also can you please send the parameters passed to parted?
(When running with trace enabled
this should be written to the logs. Please run something like
export DIB_DEBUG_TRACE="255"
disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm | tee o.log
and send the output of
grep parted o.log


Hmm, I get no output at all...

I've thrown the entire o.log contents into paste here:

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

Best,
-jay



===

To be on the same page, here are the other infos Jay send:


o Can you please provide the DIB version?


ii  python-dib-utils 0.0.6-1
ii  python-diskimage-builder 1.0.0-1


o Are you using UEFI on the host system?
(For me your command works and this question is about
 a possible difference: '--target=i386-pc' appears
 not in my logs)


Yes, it's a UEFI-enabled host:

jaypipes@brix-1:~$ sudo efibootmgr
BootCurrent: 
Timeout: 1 seconds
BootOrder: ,0002,0001
Boot* ubuntu
Boot0001* Hard Drive
Boot0002* ubuntu

===

Kind regards

Andre

__
OpenStack Development Mailing List (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] Version header for OpenStack microversion support

[Sean Dague]

On 06/21/2016 01:59 AM, Clint Byrum wrote:
> Excerpts from Edward Leafe's message of 2016-06-20 20:41:56 -0500:
>> On Jun 18, 2016, at 9:03 AM, Clint Byrum  wrote:
>>
>>> Whatever API version is used behind the compute API is none of the user's
>>> business.
>>
>> Actually, yeah, it is.
>>
>> If I write an app or a tool that expects to send information in a certain 
>> format, and receive responses in a certain format, I don't want that to 
>> change when the cloud operator upgrades their system. I only want things to 
>> change when I specifically request that they change by specifying a new 
>> microversion.
>>
> 
> The things I get back in the compute API are the purview of the compute
> API, and nothing else.
> 
> Before we go too far down this road, is there actually an example of
> one API providing a proxy to another directly? If so, is it something
> we think is actually a good idea?

There are a ton of pure proxies in Nova, which are now getting
deprecated. We do have semantic break on the images proxy in Newton
because Glance v2 has different data restrictions than Glance v1.
(metadata keys are now case sensitive, and certain properties are now
reserve words).

> Because otherwise, the API I'm talking to needs to be clear about what
> it does and does not emit and/or accept. That contract would just be
> the microversion of the API I'm talking to.

Which is fine and good in theory, and it's the theory that we're working
on. But some resources, like servers, are pretty useless without network
information, which isn't owned by Nova any more. While I don't currently
anticipate a way we couldn't mash whatever we get from Neutron into the
current format, I also have been surprised enough by future software
evolution to feel more comfortable that we have a backup plan that
includes a signaling mechanism should we need it.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Jay Pipes]

On 06/21/2016 05:43 AM, Sylvain Bauza wrote:

Le 21/06/2016 10:04, Chris Dent a écrit :

On Mon, 20 Jun 2016, Jay Pipes wrote:


Flask seems to be the most widely used and known WSGI framework so
for consistency's sake, I'm recommending we just use it and not rock
this boat. There are more important things to get hung up on than
this battle right now.


That seems perfectly reasonable. My main goal in starting the
discussion was to ensure that we reach some kind of consensus,
whatever it might be[1]. It won't be too much of an ordeal to
turn the existing pure WSGI stuff into Flask stuff.

From my standpoint doing the initial development in straight WSGI
was a win as it allowed for a lot of clarity from the inside out.
Now that that development has shown the shape of the API we can
do what we need to do to make it clear from outside in.

Next question: There's some support for not using Paste and
paste.ini. Is anyone opposed to that?



Given Flask is not something we support yet in Nova, could we discuss on
that during either a Nova meeting, or maybe wait for the midcycle ?


I really don't want to wait for the mid-cycle. Happy to discuss in the 
Nova meeting, but my preference is to have Chris just modify his patch 
series to use Flask now and review it.



To be honest, Chris and you were saying that you don't like Flask, and
I'm a bit agreeing with you. Why now it's a good possibility ?


Because Doug persuaded me that the benefits of being consistent with 
what the community is using outweigh my (and Chris') personal misgivings 
about the particular framework.



Why not Routes and Paste couldn't be using also ?


It's about using a code style and library that is in use by other 
projects so that new contributors can have some consistency in the WSGI 
handling code.


Best,
-jay


See, it's a very important question, and I remember that discussing on
Nova API v3 2 years ago was also having these kinds of discussion.

-Sylvain



[1] As long as it wasn't the overly complex Nova way.

Or WSME!



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




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



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

[openstack-dev] [Nova] Live migration meeting today

[Murray, Paul (HP Cloud)]

Agenda here: https://wiki.openstack.org/wiki/Meetings/NovaLiveMigration

We will go over the non-priority feature status today

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

[openstack-dev] [nova] PCI Based NUMA Scheduling can't really achieve pci numa binding in some cases

[ni . jinquan]

Hi,

In the current implementation scheme:
/nova/pci/stats.py

 def _filter_pools_for_numa_cells(pools, numa_cells):
# Some systems don't report numa node info for pci devices, in
# that case None is reported in pci_device.numa_node, by adding 
None
# to numa_cells we allow assigning those devices to instances with
# numa topology
numa_cells = [None] + [cell.id for cell in numa_cells]
#
If some compute nodes don't report numa node info for pci devices.
Then these pci devices will be regarded as "belong to all numa node" to 
deal with by default.
This can lead to a problem:
Pci devices is not on the numa node which CPU\MEM on.
In this way, the real purpose of I/O (PCIe) Based NUMA Scheduling is not 
reached.
More serious is that the user will be wrong thought pci devices is on the 
numa node that CPU\MEM on.
The truth is, there are still many systems don't report numa node info for 
pci devices.
So, i think this bug need fixed.

#link：
https://bugs.launchpad.net/nova/+bug/1551504
 
https://review.openstack.org/#/c/298179/

Best regards，

Jinquan Ni


Ni Jinquan  倪进权
NAIL, NIV Nanjing Dept.I



R Building, ZTE Plaza, #6 Huashen Ave. 
Yuhuatai District, Nanjing, P.R.China, 210012
T: +86 025-52877383M: +86 13584094152
E: ni.jinq...@zte.com.cn
www.zte.com.cn

欢迎访问OpenCOS门户  http://opencos.zte.com.cn 


ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

[Tomas Sedovic]

On 06/20/2016 06:37 PM, Joe Talerico wrote:

Hello - It would seem there is a little bit of overlap with TripleO
validations ( clapper validations ) and Browbeat *Checks*. I would
like to see these two come together, and I wanted to get some feedback
on this.

For reference here are the Browbeat checks :
https://github.com/openstack/browbeat/tree/master/ansible/check

We check for common deployment mistakes, possible deployment
performance issues and some bugs that could impact the scale and
performance of your cloud... At the end we build a report of found
issues with the cloud, like :
https://github.com/openstack/browbeat/blob/master/ansible/check/browbeat-example-bug_report.log

We eventually wanted to take these findings and push them to
ElasticSearch as metadata for our result data (just so we would be
aware of any BZs or possibly missed tuning).

Anyhoo, I just would like to get feedback on consolidating these
checks into TripleO Validations if that makes sense. If this does make
sense, who could I work with to see that this happens?


Hey!

I'd love to have a single place for all the validations if it's at all 
possible.


Our repos are structured a little differently, but I hope we can come up 
with a solution that works for both uses.


The primary idea behind the tripleo-validations (née Clapper) repo is to 
have have checks in the various stages of the deployment to find 
potential hardware issues or incorrect configuration early.


We want to have these run by the cli and the web ui automatically, which 
is why we opted for the one validation (playbook) with extra metadata 
per file approach.


There are two people working on these right now: myself and Martin 
André. We're in #tripleo (mandre & shadower). Feel free to talk to 
either of us, though I suspect I may have more time for this.


We're both in the CE(S)T so there should be some overlap for realtime chat.

Tomas




Thanks
Joe

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




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

[openstack-dev] [Monasca] Locked (latched) alarms

[witold.be...@est.fujitsu.com]

Hello everyone,

I have written a short blueprint on locked/latched alarms for Monasca [1]. The 
functionality allows the operator to define an alarm which after transition to 
ALARM state, stays in that state until it is manually reset.

What name should we use for that? Locked, lockable, latched, sticky? Something 
else?

I would also welcome feedback on a general implementation idea. Should we make 
it in the same way as the deterministic alarms, by extending the 
AlarmExpression? Or would it be enough to add the property to AlarmDefinition 
(option 2)? I tend to the second solution. The change in the logic of 
monasca-thresh would then be limited to AlarmThresholdingBolt. 
evaluateThreshold as far as I understand. Craig and Roland, could you comment 
on that please?


Cheers
Witek


[1] https://blueprints.launchpad.net/monasca/+spec/locked-alarms


Witold Bedyk
Senior Software Engineer

FUJITSU Enabling Software Technology GmbH
Schwanthalerstr. 75a, 80336 München

Telefon: +49 89 360908-547
Telefax: +49 89 360908-8547
COINS: 7941-6547

Sitz der Gesellschaft: München
AG München, HRB 143325
Geschäftsführer: Dr. Yuji Takada, Hans-Dieter Gatzka, Christian Menk


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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Bogdan Dobrelya]

On 06/20/2016 08:07 PM, Clint Byrum wrote:
> Excerpts from Jesse Cook's message of 2016-06-20 16:58:48 +:
>> +1
>>
>> The points about the PWG and TC are worth some consideration.
>>
>> From my perspective, I think it would make sense for the PWG to define the
>> expected behaviors of the system, which would be an input to the
>> architecture group. The architecture group would define both prescriptive
>> (where we'd like to be) and descriptive (where we actually are...roughly)
>> architectures. This would provide both the vision for the future state and
>> understanding of current state that is necessary for us to all swim in the
>> same general direction instead of constantly running into each other. I
>> don't see the architecture as something you push down, but rather something
>> that helps each contributor ask, "Does that get us closer to where we are
>> trying to go?" I absolutely think this is something that would provide a
>> huge benefit to the organization.
>>
> 
> That sounds about right Jesse. Thanks for bringing up the PWG. I
> definitely don't think an Architecture WG would want to answer "what
> is OpenStack" alone. More like "What should the OpenStack we described
> actually look like?".

IMHO, the group shall get a global state view first, which is to collect
and process (and perhaps do a *lot* of reverse engineering and  asking
developers AND users many questions) implicit knowledge hidden in
OpenStack components and libraries.

Then answer the question "What *does* the OpenStack actually look
like?". The answer may have a form of established contracts and
behaviour models - expected vs actual, and corner cases.
Yes, SLA, timeouts, failure modes, and patterns. Not generic things the
projects already have being auto-generated in dev docs, but very
specific reverse engineered and collected as a feedback or testing
discovered, *whitespaces*.

Examples: which DB patterns each of the project/common library do
leverage in code? Sounds simple, but will require a huge amount of
reverse engineering. How much of those are NOT ready to be used with A/A
read/write transactions? And for messaging patterns and failure modes
and corner cases handling - like lost or duplicated or racing data.
Retrying, timeouts - exposed in API and implcit/hardcoded. Failure
detection for stateful components like conductors/schedulers? What are
locking expectations (strong or relaxed) for the projects that do
leverage DLM?

So, those and many more firstly to be brought to the light then set in
stone. Only after that the group may proceed with the question "What
should the OpenStack we described actually look like?" in order to a)
fit unexpected or unclear behaviour into the contracts and document them
as well, b) improve.

> 
> __
> OpenStack Development Mailing 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,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing List (not for 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] Placement API WSGI code -- let's just use flask

[Sylvain Bauza]

Le 21/06/2016 10:04, Chris Dent a écrit :

On Mon, 20 Jun 2016, Jay Pipes wrote:

Flask seems to be the most widely used and known WSGI framework so 
for consistency's sake, I'm recommending we just use it and not rock 
this boat. There are more important things to get hung up on than 
this battle right now.


That seems perfectly reasonable. My main goal in starting the
discussion was to ensure that we reach some kind of consensus,
whatever it might be[1]. It won't be too much of an ordeal to
turn the existing pure WSGI stuff into Flask stuff.

From my standpoint doing the initial development in straight WSGI
was a win as it allowed for a lot of clarity from the inside out.
Now that that development has shown the shape of the API we can
do what we need to do to make it clear from outside in.

Next question: There's some support for not using Paste and
paste.ini. Is anyone opposed to that?



Given Flask is not something we support yet in Nova, could we discuss on 
that during either a Nova meeting, or maybe wait for the midcycle ?


To be honest, Chris and you were saying that you don't like Flask, and 
I'm a bit agreeing with you. Why now it's a good possibility ?


Why not Routes and Paste couldn't be using also ?
See, it's a very important question, and I remember that discussing on 
Nova API v3 2 years ago was also having these kinds of discussion.


-Sylvain



[1] As long as it wasn't the overly complex Nova way.

Or WSME!



__
OpenStack Development Mailing List (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][qos] Egress minimum bandwidth assurance

[Hirofumi Ichihara]

On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote:


Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a POC 
of this feature.


Scenario 1:

3 VM connected to br-int, sending traffic through br-physical to other 
host (an external physical machine).


The first VM will have a min BW of 15 Mb. The physical port will be 
limited to 20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW.


Those three VM are using iperf to inject traffic against the external 
host.


A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.


B) Another qos policy and queue with this minimum BW is created at 
int-phy-patchport. The traffic is not shapped.


C) Another qos policy and queue with this minimum BW is created at 
phy-int-phy-patchport. The traffic is not shapped.


D) Another qos policy and queue with this minimum BW is created at 
physical port. The traffic is still not shapped.


In OVS all traffic from VM1 is filtered to match the correct qos and 
queues at the ports.


It seems that this scenario doesn't expect some scenarios like DVR and 
multiple NIC. I thought that the queue should be set in br-int with 
veth(instead of patch port) between br-int and bt-tun. However, I guess 
that this may occur a issue that traffic cannot turn back in br-int. 
That may happen in Scenario2 case.


Therefore, I think that we should set the queue to physical port but we 
have a problem how do we specify the NIC in some cases(vlan, vxlan, DVR 
mode router and DVR FloatingIP).




Scenario 2:

Similar to scenario 1, but using a fourth VM to act as server. In this 
case, traffic only goes through br-int.


A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.


B) Another qos policy and queue with this minimum BW is created at 
output port (VM4 server port). The traffic is still not shapped.



I think we cannot manage this case because we doesn't know MAX bandwidth 
of traffic in br-int and the bandwidth is usually enough.
We should focus our attention on a case that the traffic goes out to 
other nodes.


Thanks,
Hirofumi

I need some help with this implementation, because I’m running out of 
time an ideas!


Thank you in advance.



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


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

Re: [openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

[Tomas Sedovic]

On 06/20/2016 08:58 PM, Assaf Muller wrote:

On Mon, Jun 20, 2016 at 12:43 PM, Joe Talerico  wrote:

On Mon, Jun 20, 2016 at 12:41 PM, Ihar Hrachyshka  wrote:



On 20 Jun 2016, at 18:37, Joe Talerico  wrote:

Hello - It would seem there is a little bit of overlap with TripleO
validations ( clapper validations ) and Browbeat *Checks*. I would
like to see these two come together, and I wanted to get some feedback
on this.

For reference here are the Browbeat checks :
https://github.com/openstack/browbeat/tree/master/ansible/check

We check for common deployment mistakes, possible deployment
performance issues and some bugs that could impact the scale and
performance of your cloud... At the end we build a report of found
issues with the cloud, like :
https://github.com/openstack/browbeat/blob/master/ansible/check/browbeat-example-bug_report.log

We eventually wanted to take these findings and push them to
ElasticSearch as metadata for our result data (just so we would be
aware of any BZs or possibly missed tuning).

Anyhoo, I just would like to get feedback on consolidating these
checks into TripleO Validations if that makes sense. If this does make
sense, who could I work with to see that this happens?


Sorry for hijacking the thread somewhat, but it seems that neutron-sanity-check 
would cover for some common deployment issues, if utilized by projects like 
browbeat. Has anyone considered the tool?

http://docs.openstack.org/cli-reference/neutron-sanity-check.html

If there are projects that are interested in integrating checks that are 
implemented by neutron community, we would be glad to give some guidance.

Ihar


Hey Ihar - the TripleO validations are using this :
https://github.com/rthallisey/clapper/blob/0881300a815f8b801a38d117b8d01b42a00c7f7b/ansible-tests/validations/neutron-sanity-check.yaml


Oops, that's missing a bunch of configuration files. Here's the
configuration values it expects:
https://github.com/openstack/neutron/blob/master/neutron/cmd/sanity_check.py#L32

And here's how the tool uses them:
https://github.com/openstack/neutron/blob/master/neutron/cmd/sanity_check.py#L272

It runs specific checks according to configuration file values. Is
ipset enabled in the OVS agent configuration file? Great, let's check
we can use it and report back if there's any errors.


Aah, thanks for letting us know! I'll update the validation.

Tomas






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


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


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




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