Re: [openstack-dev] [Ironic] Driver documentation in Ironic

[Ruby Loo]

>
> 2) Driver docs may not be backported to stable branches. This is a
> stable maintenance policy, not an Ironic policy. This problem is
> somewhat unique to Ironic as most major projects have deployer docs in
> the Ops guide repo, rather than in the code repo. I'm going to chat with
> some docs/stable maintenance people in Tokyo about this, however I also
> encourage you to do the same.
>
>
I think the issue of updating documentation on stable branches goes beyond
driver docs. I question whether we should be bundling the release-related
documentation with the code if it is near impossible to update that
documentation after a branch is created. For example, we have links to
release-related documentation, but they aren't correct. We released 4.2.1
(on stable/liberty branch), and the release notes there [0] don't show
release information for 4.2.1. You have to go to master [1] to see it :-(

How do the other projects do it (correctly), or is ironic the only one so
far that has in-tree documentation? It seems that after a stable branch is
cut for (some) projects, the docs team has 1 month or so beyond that to get
the documentation out. It would be great if the docs we currently maintain
in-tree could follow a similar schedule. (And how does the doc team deal
with updates to documentation for prior releases?)

--ruby

[0] http://docs.openstack.org/developer/ironic/4.2.1/releasenotes/index.html
[1] http://docs.openstack.org/developer/ironic/releasenotes/index.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] [ironic] Next meeting is November 9

[Beth Elwell]

Hi Jim,

I will be on holiday the week of the 9th November and so will be unable to make 
that meeting. Work on the ironic UI will be posted in the sub team report 
section and if anyone has any questions regarding it please shoot me an email 
or ping me.

Thanks!
Beth

> On 22 Oct 2015, at 01:58, Jim Rollenhagen  wrote:
> 
> Hi folks,
> 
> Since we'll all be at the summit next week, and presumably recovering
> the following week, the next Ironic meeting will be on November 9, in
> the usual place and time. See you there! :)
> 
> // jim
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][sriov] SRIOV-VM could not work well with normal VM

[yujie]

I used ixgbe and vlan, passthrough a VF to vm.
After the VM created, it could not connect to VM on the same compute 
node without use sriov.


在 2015/10/22 10:58, Alexander Duyck 写道:

I assume by Intel cards you mean something that is running ixgbe?  If so
and you are trying to use SR-IOV with OVS and VLANs running on top of
the PF it will fail. The issue is that OVS requires the ability to place
the PF in promiscuous mode to support VLAN trunking, and ixgbe driver
prevents that when SR-IOV is enabled.

The "bridge fdb add" approach mentioned should work as long as ixgbe PF
is used on a flat network.

- Alex

On 10/19/2015 07:33 PM, yujie wrote:

Hi Moshe Levi,
   Sorry for replying to this message after so long time. The testing
environment was unavailable before.
   I use Intel cards, but could only tested base kilo and vlan. Could
it work?

在 2015/9/22 13:24, Moshe Levi 写道:

Hi Yujie,

There is a patch https://review.openstack.org/#/c/198736/ which I
wrote to add the mac of the normal instance to
the SR-IOV embedded switch so that the packet will go to the PF
instead of going to the wire.
This is done by using bridge tool with the command "bridge fdb add
 dev "

I was able to test it on Mellanox ConnectX3  card with both vlan and
flat network and it worked fine.
I wasn't able to test it on any of the Intel cards, but I was told
the it only working on flat network, in vlan network the Intel card
is dropping the tagged packets and they are not go up to the VF.

What NIC are you using? Can you try using "bridge fdb add  dev
" where  is the mac of the normal vm and 
is the PF
and see if  that resolve the issue.
Also can you check it with  flat and vlan networks.


-Original Message-
From: yujie [mailto:judy_yu...@126.com]
Sent: Tuesday, September 22, 2015 6:28 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][sriov] SRIOV-VM could not work
well with normal VM

Hi all,
I am using neutron kilo without dvr to create sriov instance VM-A,it
works well and could connect to its gateway fine.
But when I let the normal instance VM-B which in the same
compute-node with VM-A ping its gateway, it failed. I capture the
packet on the network-node, find the gateway already reply the
ARP-reply message to VM-B. But compute-node which VM-B lives could
not send the package to VM-B.
If delete VM-A and set : echo 0 >
/sys/class/enp5s0f0/device/sriov_numvfs, the problem solved.

Is it a same question with the bug: SR-IOV port doesn't reach OVS
port on same compute node ?
https://bugs.launchpad.net/neutron/+bug/1492228
Any suggestions will be grateful.

Thanks,
Yujie


__

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

__

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




__

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



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



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

Re: [openstack-dev] [kolla] Integrating kollacli as python-kollaclient

[Paul Bourke]

Having used the cli for some time I can vouch for it being very useful, 
and usable. The guys have done a nice job of giving it an "OpenStack 
feel", mimicking the patterns used in openstackclient and the like.


It should give users a more polished introduction to Kolla.

+1

-Paul

On 21/10/15 23:20, Steven Dake (stdake) wrote:

Hello Folks,


Oracle has developed a CLI tool for managing OpenStack Kolla clusters.
Several months ago at our midcycle, the topic was brought up an I
suggested to go ahead and get started on the work.  We clearly didn't
spend enough time discussing how it should be integrated into the code
base or developed or even what its features should be, and that is my error.


What ended up happening is sort of a code dump, which is not ideal, but
I can only work so many 20 hour days ;)  I didn't believe our community
had the bandwidth to deal with integrating a CLI directly into the tree
while we were focused on our major objective of implementing Ansible
deployment of OpenStack in Docker containers.  Possibly the wrong call,
but it is what it is and it is my error, not Oracles.


The code can be cloned from:

git clone git://oss.oracle.com/git/openstack-kollacli.git


The code as is is very high quality but will likely need to go through
alot of refactoring to ReST-ify it.  There are two major authors of the
code, Borne Mace and Steve Noyes.


I'd like a majority vote from the core team as to whether we should add
this repository to our list of governed repositories in the OpenStack
Kolla governance repository here:


https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1509


Consider this email a +1 vote from me.


A completely separate email thread and decision will be made by the
community about core team membership changes to handle maintenance of
the code.  Assuming this code is voted into Kolla's governance, I plan
to propose Borne as a core reviewer, which will be open to core team
vote as a separate act with our 3 +1 votes no vetos within 1 week
period.  We will address that assuming a majority vote of the code merge
wins.  Steve can follow the normal processes for joining the core team
if he wishes (reviewing patches) - clearly his code contributions are
there.  Borne already does some reviews, and although he isn't a top
reviewer, he does have some contribution in this area making it into the
top 10 for the Liberty cycle.



Kolla CLI Features:

  * dynamic ansible inventory manipulation via the host, group and
service commands
  * ssh key push via the host setup command
  * ssh key validation via the host check command
  * ansible deployment via the deploy command
  * property viewing and modification with the property list, set and
clear commands
  * cleanup of docker containers on a single, multiple or all hosts via
the host destroy command
  * debug data collection via the dump command
  * configuration of openstack passwords via the password command
  * Lines of python = 2700
  * Lines of  test case code =  1800
  * ~ 200 commits




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



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

Re: [openstack-dev] [Heat][Rant] About blank rechecks

[Sergey Kraynev]

On 22 October 2015 at 10:58, Thomas Herve  wrote:
> Hi all,
>
> You've seen me complain about people doing blank rechecks in Gerrit on IRC,
> and it seems it had little to no effect. So here I am trying to spread the
> word here. I'll try to stay calm.
>
> I'm seeing way too many rechecks on heat patches. It's not epidemic, but
> it's still enough to make me sad.
>
> First, it makes me sad as a developer. I don't know if it's just me, but one
> of the reason I code is curiosity, and debugging a gate failure is a great
> way to learn, pierce through the layers, and improve the situation.
>
> It then makes me sad as a team member. By doing a recheck you're basically
> implying that you don't care about the failure, and surely someone will care
> at some point. Except, the information will be lost, and we may have 100
> builds before that happen again, when a release already happened, and we
> have to backport it. Working early means working less.
>
> And finally, it makes me sad for the infra team. Doing a recheck is
> disrespecting all the work they're doing to create a reliable environment to
> run our tests. Sure, sometimes the environment is the reason the failure
> happens, but then it's even more important to give feedback about it. They
> provide a great deal of logs, we can use logstach to find patterns, the
> least we can do is trying. We're also using resources that other projects
> could be using. As much as we'd like to believe it, the cloud doesn't have
> free infinite resources.
>
> Recently, I've seen many cases where rechecks were made whereas:
> 1) The heat branch was broken. Generally for some external reason (a
> dependency updated), doing a recheck is a pure waste of resources until that
> failure is fixed. Most of the time, we say something on IRC when it's the
> case. We also try to open a bug, so looking at launchpad can show something.
> 2) THE PATCH WAS ACTUALLY BROKEN. And there I'm not sad anymore I'm
> particularly angry. It basically means that you didn't look at all at the
> build results, and just mindlessly typed rechecks hoping that some fairy
> will fix your broken code. Frankly, that makes want to go on a -2 rampage.
> ESPECIALLY where a core is doing it.
>
> To close, I'll try to provide a solution. I know we all have our agenda,
> debugging gate failures takes some time that you may not have, and obviously
> "my patch is fine it's not my fault" (who cares, that's what being in a team
> means). Still, I'd like everyone to look at the test failures, look if the
> patch is not the problem, and if not open a bug [1] mentioning the test
> name, pasting the traceback in the description, and linking the build
> result. Then do recheck bug #xyz. That's it. It shouldn't take you more than
> 3 minutes, and at least we didn't lose the information.
>
> Thanks for reading that far and sorry for the length,
>
>
> [1] https://bugs.launchpad.net/heat/+filebug
>
> --
> Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Thomas,

Thank you for the pay attention on this issue.
I know that you constantly ask about it, especially core-team members :)
I appreciate it, because it's really helpful and more over important.

Unfortunately new approach with empty reverify made people more lazy.
I think, that we should follow your recommendation, because:
 - it will help fix our gate faster
 - makes our develop process more clear and useful for new comers

my +2 for this initiative.
Everybody please spent your 2-3 minutes to make our work better!

-- 
Regards,
Sergey.

__
OpenStack Development Mailing 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] [Heat][Rant] About blank rechecks

[Thomas Herve]

Hi all,

You've seen me complain about people doing blank rechecks in Gerrit on IRC,
and it seems it had little to no effect. So here I am trying to spread the
word here. I'll try to stay calm.

I'm seeing way too many rechecks on heat patches. It's not epidemic, but
it's still enough to make me sad.

First, it makes me sad as a developer. I don't know if it's just me, but
one of the reason I code is curiosity, and debugging a gate failure is a
great way to learn, pierce through the layers, and improve the situation.

It then makes me sad as a team member. By doing a recheck you're basically
implying that you don't care about the failure, and surely someone will
care at some point. Except, the information will be lost, and we may have
100 builds before that happen again, when a release already happened, and
we have to backport it. Working early means working less.

And finally, it makes me sad for the infra team. Doing a recheck is
disrespecting all the work they're doing to create a reliable environment
to run our tests. Sure, sometimes the environment is the reason the failure
happens, but then it's even more important to give feedback about it. They
provide a great deal of logs, we can use logstach to find patterns, the
least we can do is trying. We're also using resources that other projects
could be using. As much as we'd like to believe it, the cloud doesn't have
free infinite resources.

Recently, I've seen many cases where rechecks were made whereas:
1) The heat branch was broken. Generally for some external reason (a
dependency updated), doing a recheck is a pure waste of resources until
that failure is fixed. Most of the time, we say something on IRC when it's
the case. We also try to open a bug, so looking at launchpad can show
something.
2) THE PATCH WAS ACTUALLY BROKEN. And there I'm not sad anymore I'm
particularly angry. It basically means that you didn't look at all at the
build results, and just mindlessly typed rechecks hoping that some fairy
will fix your broken code. Frankly, that makes want to go on a -2 rampage.
ESPECIALLY where a core is doing it.

To close, I'll try to provide a solution. I know we all have our agenda,
debugging gate failures takes some time that you may not have, and
obviously "my patch is fine it's not my fault" (who cares, that's what
being in a team means). Still, I'd like everyone to look at the test
failures, look if the patch is not the problem, and if not open a bug [1]
mentioning the test name, pasting the traceback in the description, and
linking the build result. Then do recheck bug #xyz. That's it. It shouldn't
take you more than 3 minutes, and at least we didn't lose the information.

Thanks for reading that far and sorry for the length,


[1] https://bugs.launchpad.net/heat/+filebug

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

[openstack-dev] [Glance] Next meeting on November 12th

[Flavio Percoco]

Greetings,

Just as a reminder, our next meeting will be on November 12th. We've
decided to skip this week's meeting as many folks are already heading
to Japan. Next week we'll be at the summit and the week after, it's
likely that some folks will take time off to travel around the country
or on their way back home.

For urgent matters, discussions and other meeting topics, please, use
this mailing list or IRC.

Thank you and safe travels to everyone!
Flavio

--
@flaper87
Flavio Percoco


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] [Neutron][Nova] Trunk port feature (VLAN aware VMs)

[Ildikó Váncsa]

Hi Armando,

Great, thank you for the pointers and hints. I will contact Rossella to move 
forward with the process and implementation.

Best Regards,
/Ildikó

> -Original Message-
> From: Armando M. [mailto:arma...@gmail.com]
> Sent: October 22, 2015 01:00
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Bence Romsics; Petr Savelyev
> Subject: Re: [openstack-dev] [Neutron][Nova] Trunk port feature (VLAN aware 
> VMs)
> 
> 
> 
> On 21 October 2015 at 15:40, Ildikó Váncsa  wrote:
> 
> 
>   Hi Folks,
> 
>   During Liberty we started the implementation of the VLAN aware VMs 
> blueprint
> (https://review.openstack.org/#/c/94612/). We had quite a good progress, 
> although we could use some extra hands on Neutron side
> and some thoughts on the Nova-Neutron interaction aspect of the feature.
> 
>   The status of the code can be checked here:
>   
> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/vlan-aware-
> vms,n,z
>   https://review.openstack.org/#/q/status:open+project:openstack/python-
> neutronclient+branch:master+topic:bp/vlan-aware-vms,n,z
>   https://review.openstack.org/#/c/213120/
>   The spec proposed for Nova can be found here:
>   https://review.openstack.org/#/c/213644/
> 
> 
>   We also added a note to the corresponding cross-project session to 
> discuss further the impacts of this feature on Nova:
>   
> https://mitakadesignsummit.sched.org/event/c2292316e85e922a9a649191ad1e0160#.VigTqpeLJ4M
>   
> https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-integration
> 
>   If you are interested in this feature and would like to help out please 
> let me know. If you will be in Tokyo, we can catch
> up during/after the cross-project session or set up a separate discussion to 
> move forward and speed up the feature implementation.
> 
> 
> 
> Hi,
> 
> Thanks for the email. We discussed blueprint [1] during the last IRC meeting 
> [2] and based on our latest blueprint procedures [3],
> Rossella has volunteered to help you through the process. She is going to be 
> the main point of contact for anything related to the
> feature. We'll watch the progress of the blueprint over the course of the 
> cycle and the meeting participation is encouraged to
> raise/discuss blockers.
> 
> HTH
> Armando
> 
> [1] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
> [2] 
> http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-10-20-14.00.log.html
> [3] 
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
> 
> 
> 
>   Thanks and Best Regards,
>   Ildikó
>   (IRC: ildikov)
> 
>   
> __
>   OpenStack Development Mailing List (not for usage questions)
>   Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 

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

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Sergey Vasilenko]

On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer  wrote:

> I thought we had code in other places that split out stderr and only
> logged it if there was an actual error but I cannot find the reference now.
> I think that matches the original proposal. Not sure I like idea #3.


Matthew, this topic not about SSL. ANY warnings, ANY output to stderr from
CLI may corrupt work of providers from puppet-* modules for openstack
components.

IMHO it's a very serious bug, that potential affect openstack puppet
modules.

I see 3 way for fix it:

   1. Long way. big patch to puppet core for add ability to collect stderr
   and stdout separately. But most of existing puppet providers waits that
   stderr and stdout was mixed when handle errors of execution (non-zero
   return code). Such patch will broke backward compatibility, if will be
   enabled by default.
   2. Middle way. We should write code for redefine 'commands' method. New
   commands should collect stderr and stdout separately, but if error happens
   return stderr (with ability access to stdout too).
   3. Short way. Modify existing providers to use json output instead
   plain-text or csv. JSON output may be separated from any garbage (warnings)
   slightly. I make this patch as example of this way:
   https://review.openstack.org/#/c/238156/ . Anyway json more formalized
   format for data exchange, than plain text.

IMHO way #1 is a best solution, but not easy.

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

[openstack-dev] [ironic] Ironic design summit schedule

[Wan-yen Hsu]

Hi Jim,

  I have asked techtalk coordinator to switch my techtalk session time so
there is no need to change group management session schedule.  You can keep
it  at 2:50pm Wed.. Thanks!


wanyen
__
OpenStack Development Mailing 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] [Congress] Monasca @10a on Thu in Tokyo

[Tim Hinrichs]

Hi all,

At the summit next week, we're planning on a 10a meeting on Thursday with
the Monasca team for a deep dive.  All are welcome.

Tim
__
OpenStack Development Mailing 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] PGP keysigning party for Mitaka summit in Tokyo?

[gustavo panizzo (gfa)]

Hello
I see that 
https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Mitaka_Summit
is empty and no email thread about the topic, will be any more or less
formal keysigning party in Tokyo?

is it too late?


-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa

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

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

[Michael Xin]

Mike:
Got it. Thanks. We will update it. 


Yours,
Michael 




On 10/22/15, 12:18 PM, "michael mccune"  wrote:

>On 10/21/2015 05:11 PM, Michael Xin wrote:
>> Rob and Michael:
>> Thanks for the update. We will probably not use any Openstack Logo.
>>
>> Here is the first draft of the flyer:
>>
>> http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf
>>
>>
>> Please send us your feedback.
>
>i think my only suggestion on the text would be to slightly alter the 
>second sentence of the "What's the OSSP?" section.
>
>currently it is:
>
>"The Security Project undertakes both technical and governance 
>activities within OpenStack, aiming to provide guidance, information and 
>code that enhances the overall security of the OpenStack ecosystem"
>
>i would change the beginning to:
>
>"The Security Project undertakes both technical and governance 
>activities for the OpenStack community, aiming to provide guidance, 
>information and code that enhances the overall security of the OpenStack 
>ecosystem"
>
>but i think this is a pretty minor nit.
>
>regards,
>mike
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for 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] Migration state machine proposal.

[Joshua Harlow]

Nikola Đipanov wrote:

On 10/21/2015 10:17 PM, Joshua Harlow wrote:

Question on some things seen in the below paste.

What is with 'finished' ->  'reverted' and 'finished' ->  'confirmed'?

Why does it jump over 'reverting' or 'confirming'? Should it?

The other question is the difference between 'failed' and 'error' in the
first diagram, any idea on why/how these are semantically different? The
difference between 'done' and 'finished' are also in my mind
semantically confusing.

Overall I'm very much inclined to have three state machines (one for
each type), vs the mix-mash of all three into one state machine (which
causes the confusion around states in the first diagram in that paste).



So the problem here is that they (as you point out) grew organically,
and we are exposing these through the API. We need to keep them, and I
see this BP as simply documenting them with automaton thrown in for it's
validation and documenting features.

So - we _do not_ want to change these. Think of them as information for
human consumption.


Sure, I'm all for not changing them (right now), or changing them after 
we have them explicitly defined and can easily understand what they are 
(vs right now where it is implicit and not easily understandable); one 
step at a time I guess :)




What we may want to do is add an additional field (called state instead
of status maybe), that we can use to re-boot states, and define better
state machines that are easier to write tooling against. This is a
separate effort, that will surely need a spec and a discussion to get
the states right.

That's what we (or at least I) were talking about.
N.


Josh

Tang Chen wrote:

Hi,

Please help to take a look at this problem. I was trying to raise it in
the spec discussion.
But since we don't need a spec on this problem, so I want to discuss it
here.
It is about what the new state machine will be.

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

Thanks.




__

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

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



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


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

Re: [openstack-dev] [keystone] [nova] [cinder] Mitaka summit working session: Resource Federation for an Open Cloud

[Iury Gregory]

Hi George, can you say day and hour for this working session? Thanks

2015-10-19 18:31 GMT-03:00 Sean McGinnis :

> On Mon, Oct 19, 2015 at 12:27:53PM -0400, George Silvis, III wrote:
> > Hello everyone,
> >
> > Since the Liberty summit, we have been working on prototyping the
> > changes needed for inter-Openstack deployment resource federation[1].
> > We now have a demo to show, in which users can attach Cinder volumes to
> > Nova instances in other Openstack deployments.
> >
> > Although all of our changes are to Nova, the changes have implications
> > for Cinder and Keystone as well.  So, with the help of the Nova team, we
> > are in the process of organizing a cross-project session at the Mitaka
> > design summit.  We're especially looking for Nova, Cinder, and Keystone
> > developers to attend and give feedback.
>
> Thanks for the heads up George. As long as this doesn't conflict with
> any of our Cinder design sessions, I will definitely plan on being
> there.
>
> >
> > At the session, we will start by giving a short demo.  We'll show it in
> > action, talk about the design we used, and show the changes to the Nova
> > codebase and API that we made.  The goal of the rest of the session will
> > be to figure out the next steps to contributing our changes to upstream
> > Openstack.
> >
> > We are working on a blueprint and specification for our changes.  We
> > have a provisional blueprint[2], which we will update based on our
> > feedback at the design session.  We do not currently have a
> > specification, but we have some design thoughts available on our wiki[3].
> >
> > Best,
> >  -George Silvis, III
> >  -MOC/OCX team
> >
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/066445.html
> >
> > [2]
> >
> https://blueprints.launchpad.net/nova/+spec/mix-and-match-resource-federation
> >
> > [3] https://github.com/CCI-MOC/moc-public/wiki/Mix-and-Match-Federation
> >
> >
> >
>
>
>
> >
> __
> > OpenStack Development Mailing 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
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@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] [heat] Shared code between server and client

[Jay Dobies]

I'm working on moving the functionality for merging environments from 
the client into the server [1]. I've only superficially looked at 
template_utils.py (in heatclient) but I'm guessing there is stuff in 
there I will want to use server-side.


The server has a requirement on heatclient, but I'm not sure what the 
convention is for using code in it. Can I directly call into a module in 
heatclient/common from the server or is the client dependency only 
intended to be used through the client-facing APIs?


[1] https://blueprints.launchpad.net/heat/+spec/multi-environments

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] [Fuel] Remove nova-network as a deployment option in Fuel?

[Mike Scherbakov]

Hi all,
I'm back to this thread. Who can take a lead here and remove nova-network
starting from 8.0 and all following releases?


On Thu, Oct 1, 2015 at 3:15 AM Sergii Golovatiuk 
wrote:

> Hi,
>
> Can we get the latest supported release version? We will remove from
> nailgun after End of Life of that particular release...
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

[Oleg Gelbukh]

Igor, it is interesting that you mention backward compatibility in this
context.

I can see lots of code in Nailgun that checks for release version to
enable/disable features that were added or removed more than 2 releases
before [1] [2] [3] (there's a lot more).

What should we do about that code? I believe we could 'safely' delete it.
It will make our code base much more compact and supportable without even
decoupling serializers, etc. Is my assumption correct, or I just missing
something?

This will also help to switch to another scheme of versioning of releases,
since there will be much less places where those version scheme is
hardcoded.

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/release.py#L142-L145
[2]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L554-L555
[3]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/serializers/node.py#L124-L126

--
Best regards,
Oleg Gelbukh

On Mon, Oct 19, 2015 at 6:34 PM, Igor Kalnitsky 
wrote:

> Oleg,
>
> I think we can remove this function for new releases and keep them
> only for backward compatibility with previous ones. Why not? If
> there's a way to do things better let's do them better. :)
>
> On Sat, Oct 17, 2015 at 11:50 PM, Oleg Gelbukh 
> wrote:
> > In short, because of this:
> >
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/release.py#L74-L99
> >
> > Unless we use dashed 2-component version where OpenStack version comes
> > first, followed by version of Fuel, this will break creation of a cluster
> > with given release.
> >
> > -Oleg
> >
> > On Sat, Oct 17, 2015 at 10:24 PM, Sergii Golovatiuk
> >  wrote:
> >>
> >> Why can't we use 'liberty' without 8.0?
> >>
> >> On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh 
> wrote:
> >>>
> >>> After closer look, the only viable option in closer term seems to be
> >>> 'liberty-8.0' version. It does not to break comparisons that exist in
> the
> >>> code and allows for smooth transition.
> >>>
> >>> --
> >>> Best regards,
> >>> Oleg Gelbukh
> >>>
> >>> On Fri, Oct 16, 2015 at 5:35 PM, Igor Kalnitsky <
> ikalnit...@mirantis.com>
> >>> wrote:
> 
>  Oleg,
> 
>  Awesome! That's what I was looking for. :)
> 
>  - Igor
> 
>  On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh 
>  wrote:
>  > Igor,
>  >
>  > Got your question now. Coordinated point (maintenance) releases are
>  > dropped.
>  > [1] [2]
>  >
>  > [1]
>  >
> http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html
>  > [2]
>  >
>  >
> https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases
>  >
>  > --
>  > Best regards,
>  > Oleg Gelbukh
>  >
>  > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky
>  > 
>  > wrote:
>  >>
>  >> Oleg,
>  >>
>  >> Yes, I know. Still you didn't answer my question - are they
> planning
>  >> to release stable branches time-to-time? Like I said, Liberty is
>  >> something similar 2015.2.0. How they will name release of something
>  >> like 2015.2.1 (stable release, with bugfixes) ? Or they plan to
> drop
>  >> it?
>  >>
>  >> Thanks,
>  >> Igor
>  >>
>  >> On Fri, Oct 16, 2015 at 1:02 PM, Oleg Gelbukh <
> ogelb...@mirantis.com>
>  >> wrote:
>  >> > Igor,
>  >> >
>  >> > The point is that there's no 2015.2.0 version anywhere in
>  >> > OpenStack. So
>  >> > every component will be versioned separately, for example, in
>  >> > Libery,
>  >> > Nova
>  >> > has version 12.0.0, and minor release of it is going to have
>  >> > version
>  >> > 12.0.1,
>  >> > while Keystone, for instance, will have version 11.0.0 and 11.0.1
>  >> > for
>  >> > minor
>  >> > release.
>  >> >
>  >> > The problem in Fuel is that coordinated release version is used
> in
>  >> > several
>  >> > places, the most important being installation path of the
>  >> > fuel-library.
>  >> > We
>  >> > won't be able to use it the same way since Liberty. I'd like to
>  >> > understand
>  >> > how we are going to handle that.
>  >> >
>  >> > My suggestion actually is to move away from using OpenStack
> version
>  >> > as a
>  >> > part of Fuel version. Then the path to install the fuel-library
>  >> > will be
>  >> > '/etc/puppet/8.0.0/'.
>  >> >
>  >> > --
>  >> > Best regards,
>  >> > Oleg Gelbukh
>  >> >
>  >> > On Fri, Oct 16, 2015 at 12:45 PM, Igor Kalnitsky
>  >> > 
>  >> > wrote:
>  >> >>
>  >> >> Hey Oleg,
>  >> >>
>  >> >> I've read the post [1] and I didn't get how exactly minor
> 

Re: [openstack-dev] PGP keysigning party for Mitaka summit in Tokyo?

[Jeremy Stanley]

On 2015-10-23 01:48:05 +0800 (+0800), gustavo panizzo (gfa) wrote:
> I see that
> https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Mitaka_Summit
> is empty and no email thread about the topic, will be any more or
> less formal keysigning party in Tokyo?
> 
> is it too late?

Space is tight at the venue, but it's also pretty easy to bring
slips of paper with your full name, E-mail address and key
fingerprint to give to people you run into and exchange
identification after design summit sessions, in the hallways, at
dinner/parties, et cetera. I keep that information printed on
business cards and always carry plenty with me when I travel for
conferences.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project

[michael mccune]

On 10/21/2015 05:11 PM, Michael Xin wrote:

Rob and Michael:
Thanks for the update. We will probably not use any Openstack Logo.

Here is the first draft of the flyer:

http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf


Please send us your feedback.


i think my only suggestion on the text would be to slightly alter the 
second sentence of the "What's the OSSP?" section.


currently it is:

"The Security Project undertakes both technical and governance 
activities within OpenStack, aiming to provide guidance, information and 
code that enhances the overall security of the OpenStack ecosystem"


i would change the beginning to:

"The Security Project undertakes both technical and governance 
activities for the OpenStack community, aiming to provide guidance, 
information and code that enhances the overall security of the OpenStack 
ecosystem"


but i think this is a pretty minor nit.

regards,
mike

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

Re: [openstack-dev] [nova-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Mathieu Gagné]

On 2015-10-21 10:23 AM, Markus Zoeller wrote:
> Lingxian Kong  wrote on 10/21/2015 06:44:27 AM:
> 
>> From: Lingxian Kong 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Date: 10/21/2015 06:44 AM
>> Subject: Re: [openstack-dev] [nova-compute][nova][libvirt] Extending 
>> Nova-Compute for image prefetching
>>
>> Hi, Alberto,
>>
>> I'm really interested in your proposal, have you already submitted
>> your spec? or is there any topic for you to have a discussion with
>> Nova team in design summit?
>>
>> I wonder what if the nova compute host use shared storage backend,
>> like NFS or Ceph?
>>
>> I have another suggestion, we can consider adding this capability in
>> nova manage CLI, since it's just may be used by operator or
>> administrator(at least for create/update/delete command), right?
> 
> Could you maybe add a short explanation what the use case is? IOW,
> when and why do I (in whatever role) prefetch images? 
> 

This previous OpenStack Summit presentation at Paris is a great example
of use case:

https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/cold-start-booting-of-1000-vms-under-10-minutes

-- 
Mathieu

__
OpenStack Development Mailing 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] [NFV][Telco] New use case - efficient deployment of Cassandra and other NoSQL DBs

[Calum Loudon]

Hi all

I've uploaded a new use case for comment, available at 
https://review.openstack.org/#/c/238167/.  It's to do with the efficient 
deployment of Cassandra and other NoSQL DBs.

The link to NFV and Telco may seem tenuous, but this is a real issue we are 
hitting in the field.  Telcos are very interested in running geo-redundant 
services, meaning user data must be geo-redundant.  Using scalable open-source 
N+k NoSQL DBs like Cassandra is a very common solution.  They typically provide 
redundancy at the application level by replicating data between application 
nodes, actively preferring the underlying storage not to be redundant.  They 
also require the storage attached to different application nodes to have no 
common points of failure, and (for performance reasons) to place different 
types of data on different storage pools.  Those innocent sounding requirements 
are trivial to meet in the bare metal world - give your nodes an SSD and an HDD 
and you're done - but when trying to map to OpenStack it's surprisingly 
difficult.

Enjoy.

regards

Calum

Calum Loudon 
Director, Architecture
+44 (0)208 366 1177
 
METASWITCH NETWORKS 
THE BRAINS OF THE NEW GLOBAL NETWORK
www.metaswitch.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] [Nova] Migration state machine proposal.

[Nikola Đipanov]

On 10/21/2015 10:17 PM, Joshua Harlow wrote:
> Question on some things seen in the below paste.
> 
> What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?
> 
> Why does it jump over 'reverting' or 'confirming'? Should it?
> 
> The other question is the difference between 'failed' and 'error' in the
> first diagram, any idea on why/how these are semantically different? The
> difference between 'done' and 'finished' are also in my mind
> semantically confusing.
> 
> Overall I'm very much inclined to have three state machines (one for
> each type), vs the mix-mash of all three into one state machine (which
> causes the confusion around states in the first diagram in that paste).
> 

So the problem here is that they (as you point out) grew organically,
and we are exposing these through the API. We need to keep them, and I
see this BP as simply documenting them with automaton thrown in for it's
validation and documenting features.

So - we _do not_ want to change these. Think of them as information for
human consumption.

What we may want to do is add an additional field (called state instead
of status maybe), that we can use to re-boot states, and define better
state machines that are easier to write tooling against. This is a
separate effort, that will surely need a spec and a discussion to get
the states right.

That's what we (or at least I) were talking about.
N.

> Josh
> 
> Tang Chen wrote:
>> Hi,
>>
>> Please help to take a look at this problem. I was trying to raise it in
>> the spec discussion.
>> But since we don't need a spec on this problem, so I want to discuss it
>> here.
>> It is about what the new state machine will be.
>>
>> http://paste.openstack.org/show/476954/
>>
>> Thanks.
>>
>>
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [ironic] Next meeting is November 9

[Miles Gould]

Thanks!

Miles

- Original Message -
From: "Dmitry Tantsur" 
To: openstack-dev@lists.openstack.org
Sent: Thursday, 22 October, 2015 11:37:49 AM
Subject: Re: [openstack-dev] [ironic] Next meeting is November 9

On 10/22/2015 12:33 PM, Miles Gould wrote:
> I've just joined - what is the usual place and time?

Hi and welcome!

All the information you need you can find here: 
https://wiki.openstack.org/wiki/Meetings/Ironic

>
> Thanks,
> Miles
>
> - Original Message -
> From: "Beth Elwell" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Thursday, 22 October, 2015 8:33:03 AM
> Subject: Re: [openstack-dev] [ironic] Next meeting is November 9
>
> Hi Jim,
>
> I will be on holiday the week of the 9th November and so will be unable to 
> make that meeting. Work on the ironic UI will be posted in the sub team 
> report section and if anyone has any questions regarding it please shoot me 
> an email or ping me.
>
> Thanks!
> Beth
>
>> On 22 Oct 2015, at 01:58, Jim Rollenhagen  wrote:
>>
>> Hi folks,
>>
>> Since we'll all be at the summit next week, and presumably recovering
>> the following week, the next Ironic meeting will be on November 9, in
>> the usual place and time. See you there! :)
>>
>> // jim
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

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

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

[Vladimir Kuklin]

>
>  Each task can use some code to transform this output to the
> representation that is actually needed for this particular task. Whenever a
> task transforms this data it can access API and do version negotiation, for
> example. Each time this transformation is performed this task can return
> the data to some storage that will save this data for sake of control and
> troubleshooting, such as, for example, user can always see which changes
> are going to be applied and decide what to do next.
>
> Also, this means that the process of data calculation itself is very
> 'lazy' or 'delayed', i. e. the data itself is calculated right at the
> beginning of deployment transaction, so that it is not locked to some
> particular details of deployment engine data processing and not prone to
> issues like 'oh, I cannot get VIP because it has not been allocated yet by
> Nailgun/oh, I cannot set it because it has already been set by Nailgun and
> there is no way to alter it'.
>

>> To me, the two paragraphs above a contradictory. If the data
calculations are lazy, I don't really see how one can introspect into
changes that will be applied by a component at any given run. You just >>
don't have this information, and you need to calculate it anyways to see
which settings will be passed to a component. Might be I got your point
wrong here. Please correct me if this is the case.

Oleg, I actually meant that we do it in the following stages:

1) Change stuff in any amount of business logic engines you want,
configuration databases, wikipedia, 4chan, etc.
2) Schedule a transaction of deployment
3) Make 'transformers/serializers' for each of the task collect all the
data and store them before execution is started
4) Allow user to compare differences and decide whether he actually wants
to apply this change
5) Commit the deployment - run particular tasks with particular set of
settings which are staged and frozen (otherwise it will be impossible to
 debug this stuff)
6) If there is lack of data for some task, e.g. you need some entitties to
be created during the deployment so that other task will use their output
or side-effects to calculate things - this task should not be executed
within this transaction. This means that the whole deployment should be
splitted into 2 transactions. I can mention an old story here - when we
were running puppet we needed to create some stuff for neutron knowing ID
of the network that had been created by another resource 5 seconds earlier.
But we could not do this because puppet 'freezes' the input provided with
"facts" before this transaction runs. This is exactly the same usecase.

So these 6 items actually mean:

1) Clear separation between layers of the system and their functional
boundaries
2) Minimum of cross-dependencies between component data - e.g. deployment
tasks should not ever produce anything that is then stored in the storage.
Instead, you should have an API that provides you with data which is the
result of deployment run. E.g. if you need to create a user in LDAP and you
need this user's ID for some reason, your deployment task should create
this user and, instead of returning this output to the storage, you just
run another transaction and the task that requires this ID fetches it from
LDAP.


On Thu, Oct 22, 2015 at 1:25 PM, Dmitriy Shulyak 
wrote:

>
> Hi Oleg,
>
> I want to mention that we are using similar approach for deployment
> engine, the difference is that we are working not with components, but with
> deployment objects (it could be resources or tasks).
> Right now all the data should be provided by user, but we are going to add
> concept of managed resource, so that resource will be able to request data
> from 3rd party service before execution, or by notification, if it is
> supported.
> I think this is similar to what Vladimir describes.
>
> As for the components - i see how it can be useful, for example
> provisioning service will require data from networking service, but i think
> nailgun can act as router for such cases.
> This way we will keep components simple and purely functional, and nailgun
> will perform a role of a client which knows how to build interaction
> between components.
>
> So, as a summary i think this is 2 different problems.
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Martin Mágr]

On 10/22/2015 05:16 AM, Matt Fischer wrote:
I thought we had code in other places that split out stderr and only 
logged it if there was an actual error but I cannot find the reference 
now.

https://github.com/openstack/puppet-glance/blob/stable/kilo/lib/puppet/provider/glance.rb#L184

But it was removed in master branch for some reason.

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

Re: [openstack-dev] [Congress] Congress social night

[Peter Balland]

Hi,

I tried to register, but the link said the event was sold out.  I am
planning on attending.

Thanks,

- Peter

On 10/21/15, 7:21 PM, "Masahito MUROI" 
wrote:

>Hi Congress folks,
>
>Congress team plans to get-together on Wednesday night to be acquainted.
>
>If you are interested, please fill out quick RSVP [1] by the end of the
>week since I want to know a roughly estimated head count. If the number
>is big, I'll book sports bar, Japanese style bar called "Izakaya" or
>somewhere. The place and the time will depend on how many people want to
>go since there is official events on Wednesday night.
>
>1.
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.eventbrite.com_e_c
>ongress-2Dteam-2Ddinner-2Din-2Dtokyo-2Dsuumit-2Dtickets-2D19199371838=BQ
>ICJg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=zlP7bph5MvLMIU5tJQ_-2
>AcEk-35kD-YRDosa2Aww1E=8xdrau-62ty8A5qoxqDMw2a0ZHAItjr-ya3vD8o03sQ=W96
>JYhfc5cZcRv6DiBGgYVU3CNEMJAgikLNzzhw05fg=
>
>best regard,
>masahito
>
>-- 
>室井 雅仁(Masahito MUROI)
>Software Innovation Center, NTT
>Tel: +81-422-59-4539，FAX: +81-422-59-2699
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] Dropping support for 3.2 in a bunch of upstream projects

[Robert Collins]

Hi, so pip 8 is going to drop support for Python 3.2; setuptools 19
will drop support for it too.

This implies either pinning pip and setuptools in CI, or dropping
support for 3.2 in things where CI depends on those tools.

I know we don't specifically test or support 3.2 in OpenStack things
... but since we're a fairly big community of users of things I (help)
maintain, I thought I'd check and see whether folk here have a need
for 3.2 support - in higher level things.

So... I'm sending this email to poll for folk that *need* support for
3.2, to see how widespread the impact of dropping support would be.
(Obviously users can pin versions of the libraries that drop 3.2 - the
older releases will still be on PyPI... )

If there isn't a hue and cry about this then I think it will make
sense to drop support for Python 3.2 in mock, testtools, fixtures,
testrepository, testscenarios, testresources, unittest2, traceback2
and linecache2 - generally everything :)

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [kolla] Liberty release builds

[Steven Dake (stdake)]

Agree with Sam on these points.

We agreed in the Etherpad to push 1.0.0-liberty-monotonicincreasenumber until 
we can actually deploy that version.  Then once we have a valid test off a 
1.0.0-liberty-000 we retag that as 1.0.0-liberty which the Ansible playbook are 
set to pull by default.

Sam,

Any chance you can document the correct commands in the etheerpad to support 
this workflow?

Regards
-steve


From: Sam Yaple >
Reply-To: "s...@yaple.net" 
>, "OpenStack Development Mailing List 
(not for usage questions)" 
>
Date: Thursday, October 22, 2015 at 8:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] Liberty release builds


No you should not push with latest tag.

The initial push should have tag '1.0.0-liberty-000'. After we validate that is 
a good build we can add additional tags '1.0.0' and '1.0.0-liberty'

If the build is not good we will rebuild and repush with tag 
'1.0.0-liberty-001'. We should never be overwriting a tag or pushing a 'latest' 
tag.

On Oct 22, 2015 10:00 AM, "Paul Bourke" 
> wrote:
Ok so now liberty is tagged we can nail down the process here. Suggest we push 
first with latest, then when happy add the following tags:

* 1.0.0
* 1.0.0-liberty
* 1.0.0-liberty-release-001

===
git clone https://github.com/openstack/kolla
cd kolla
git checkout tags/1.0.0-liberty
tools/build.py \
--type source \
-- base < ... > \   # e.g. centos / ubuntu / oraclelinux / ...
--no-cache \
--push
===

Please respond with whether you're happy or not with the above. Would be nice 
to get images pushed before the summit.

Cheers,
-Paul

On 20/10/15 23:19, Steven Dake (stdake) wrote:


On 10/20/15, 9:06 AM, "Paul Bourke" 
> wrote:

Kolla core team,

Here's a link to an etherpad created just now for deciding the process
on getting release builds to dockerhub:

https://etherpad.openstack.org/p/kolla-release-builds

Please review and revise. Steve, can you follow up to this mail when
you'd like volunteers to kick off builds?

Paul,

Thanks for the initiative here!  We actually had one last minute patch
that needs to go into the tree related to Ceph failing to build
occasionally because of timers, so I decided to not push the tag until it
was resolved.  This was compounded by a node pool restart which broke
about 4 hours of CI testing of the patch that needs to go in to fix the
problem.

Once the release is tagged, we can go ahead and build for direct
consumption from the docker hub.

Regards,
-steve




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


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

Re: [openstack-dev] [kolla] Integrating kollacli as python-kollaclient

[Steven Dake (stdake)]

On 10/22/15, 5:18 AM, "Jastrzebski, Michal" 
wrote:

>Hello,
>
>I have looked at this code and it seems pretty solid. I'm not sure if it
>will be ready for governance as-is, there are few things I think have to
>be addressed before (for example I'm not sure if ansible can be
>dependency due to its license). Having said that I'd be happy to see it
>in our codebase as it will help kolla's user experience a lot.
>
>So +1 from me, thanks guys for it!
>
>Let's discuss what has to be done to get it into openstack asap, and then
>next steps. I'd like to volunteer to help you with that guys.
>
>Regard

The process to add it is simple.  If a majority of the core reviewers vote
to accept the code, someone (you volunteered?) submits a project-config
repo addition with an upstream of the proper git upstream repo to the
target of kolla-pythonclient.  I submit a change to the governance repo
first to inform the TC and broader community we are including a new
repository in our managed repo list.

Regards
-steve

>s,
>Michał
>
>> -Original Message-
>> From: Paul Bourke [mailto:paul.bou...@oracle.com]
>> Sent: Thursday, October 22, 2015 10:42 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [kolla] Integrating kollacli as
>>python-kollaclient
>> 
>> Having used the cli for some time I can vouch for it being very useful,
>>and
>> usable. The guys have done a nice job of giving it an "OpenStack feel",
>> mimicking the patterns used in openstackclient and the like.
>> 
>> It should give users a more polished introduction to Kolla.
>> 
>> +1
>> 
>> -Paul
>> 
>> On 21/10/15 23:20, Steven Dake (stdake) wrote:
>> > Hello Folks,
>> >
>> >
>> > Oracle has developed a CLI tool for managing OpenStack Kolla clusters.
>> > Several months ago at our midcycle, the topic was brought up an I
>> > suggested to go ahead and get started on the work.  We clearly didn't
>> > spend enough time discussing how it should be integrated into the code
>> > base or developed or even what its features should be, and that is my
>>error.
>> >
>> >
>> > What ended up happening is sort of a code dump, which is not ideal,
>> > but I can only work so many 20 hour days ;)  I didn't believe our
>> > community had the bandwidth to deal with integrating a CLI directly
>> > into the tree while we were focused on our major objective of
>> > implementing Ansible deployment of OpenStack in Docker containers.
>> > Possibly the wrong call, but it is what it is and it is my error, not
>>Oracles.
>> >
>> >
>> > The code can be cloned from:
>> >
>> > git clone git://oss.oracle.com/git/openstack-kollacli.git
>> >
>> >
>> > The code as is is very high quality but will likely need to go through
>> > alot of refactoring to ReST-ify it.  There are two major authors of
>> > the code, Borne Mace and Steve Noyes.
>> >
>> >
>> > I'd like a majority vote from the core team as to whether we should
>> > add this repository to our list of governed repositories in the
>> > OpenStack Kolla governance repository here:
>> >
>> >
>> > https://github.com/openstack/governance/blob/master/reference/projects
>> > .yaml#L1509
>> >
>> >
>> > Consider this email a +1 vote from me.
>> >
>> >
>> > A completely separate email thread and decision will be made by the
>> > community about core team membership changes to handle maintenance of
>> > the code.  Assuming this code is voted into Kolla's governance, I plan
>> > to propose Borne as a core reviewer, which will be open to core team
>> > vote as a separate act with our 3 +1 votes no vetos within 1 week
>> > period.  We will address that assuming a majority vote of the code
>> > merge wins.  Steve can follow the normal processes for joining the
>> > core team if he wishes (reviewing patches) - clearly his code
>> > contributions are there.  Borne already does some reviews, and
>> > although he isn't a top reviewer, he does have some contribution in
>> > this area making it into the top 10 for the Liberty cycle.
>> >
>> >
>> >
>> > Kolla CLI Features:
>> >
>> >   * dynamic ansible inventory manipulation via the host, group and
>> > service commands
>> >   * ssh key push via the host setup command
>> >   * ssh key validation via the host check command
>> >   * ansible deployment via the deploy command
>> >   * property viewing and modification with the property list, set and
>> > clear commands
>> >   * cleanup of docker containers on a single, multiple or all hosts
>>via
>> > the host destroy command
>> >   * debug data collection via the dump command
>> >   * configuration of openstack passwords via the password command
>> >   * Lines of python = 2700
>> >   * Lines of  test case code =  1800
>> >   * ~ 200 commits
>> >
>> >
>> >
>> >
>> >
>> 
>> __
>> >  OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [heat] resource_registry base_url

[Jay Dobies]

In looking through the environment file loading code, I keep seeing a 
check for base_url in the resource registry. It looks like a way to have 
the registry entries only be the filenames (I suppose relative filenames 
work as well) instead of having to enter the full path every time. The 
base_url would be used as the root URL for those filenames when loading 
them.


Thing is, I can't find any reference to that in the docs. I did a search 
for resource_registry, but the only thing I can find is [1] which 
doesn't talk about base_url.


Is this something that's still supported or was it "turned off" (so to 
speak) by removing the docs about it so users didn't know to use it? Is 
the syntax to just sit it side by side with the resource definitions, 
similar to:


resource_registry:
  "base_url": /home/jdob/my_templates
  "OS::Nova::Server": my_nova.yaml

Or am I just totally missing where in the docs it's talked about (which 
is also terribly possible)?


[1] 
http://docs.openstack.org/developer/heat/template_guide/environment.html?highlight=resource_registry


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] [heat] Shared code between server and client

[Robert Collins]

My 2c - if its a stable API in the client, and can be kept stable,
there's no problem.

-Rob

On 23 October 2015 at 08:49, Jay Dobies  wrote:
> I'm working on moving the functionality for merging environments from the
> client into the server [1]. I've only superficially looked at
> template_utils.py (in heatclient) but I'm guessing there is stuff in there I
> will want to use server-side.
>
> The server has a requirement on heatclient, but I'm not sure what the
> convention is for using code in it. Can I directly call into a module in
> heatclient/common from the server or is the client dependency only intended
> to be used through the client-facing APIs?
>
> [1] https://blueprints.launchpad.net/heat/+spec/multi-environments
>
> 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



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [heat] Shared code between server and client

[Steve Baker]

On 23/10/15 08:49, Jay Dobies wrote:
I'm working on moving the functionality for merging environments from 
the client into the server [1]. I've only superficially looked at 
template_utils.py (in heatclient) but I'm guessing there is stuff in 
there I will want to use server-side.


The server has a requirement on heatclient, but I'm not sure what the 
convention is for using code in it. Can I directly call into a module 
in heatclient/common from the server or is the client dependency only 
intended to be used through the client-facing APIs?


[1] https://blueprints.launchpad.net/heat/+spec/multi-environments

heat server already depends on heatclient, which was done so that some 
template parsing could live in heatclient and be shared by both (this 
isn't finished, and anyone who wants to pick it up is welcome to)


So yes, this would be a valid case for heat calling heatclient functions.

As an aside, it would be preferable if heatclient can somehow discover 
that it is interacting with a multi-env aware REST API, and fallback to 
local merging as appropriate.


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

Re: [openstack-dev] [heat] resource_registry base_url

[Steve Baker]

On 23/10/15 09:35, Jay Dobies wrote:
In looking through the environment file loading code, I keep seeing a 
check for base_url in the resource registry. It looks like a way to 
have the registry entries only be the filenames (I suppose relative 
filenames work as well) instead of having to enter the full path every 
time. The base_url would be used as the root URL for those filenames 
when loading them.


Thing is, I can't find any reference to that in the docs. I did a 
search for resource_registry, but the only thing I can find is [1] 
which doesn't talk about base_url.


Is this something that's still supported or was it "turned off" (so to 
speak) by removing the docs about it so users didn't know to use it? 
Is the syntax to just sit it side by side with the resource 
definitions, similar to:


resource_registry:
  "base_url": /home/jdob/my_templates
  "OS::Nova::Server": my_nova.yaml

Or am I just totally missing where in the docs it's talked about 
(which is also terribly possible)?


[1] 
http://docs.openstack.org/developer/heat/template_guide/environment.html?highlight=resource_registry


Thanks :)


I'm not sure, since I've never used an explicit base_url. I just put the 
environment file which defines the resource_registry in the same 
directory as my_nova.yaml and the relative paths will resolve. Is that 
an option for you?


__
OpenStack Development Mailing List (not for 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][Fuel] Using Native Ruby Client for Openstack Providers

[Gilles Dubreuil]

On 19/10/15 22:04, Tom Fifield wrote:
> On 13/10/15 21:13, Vladimir Kuklin wrote:
>> Puppetmaster and Fuelers,
>>
>> Last week I mentioned that I would like to bring the theme of using
>> native ruby OpenStack client and use it within the providers.
>>
>> Emilien told me that I had already been late and the decision was made
>> that puppet-openstack decided to not work with Aviator based on [0]. I
>> went through this thread and did not find any unresolvable issues with
>> using Aviator in comparison with potential benefits it could have
>> brought up.
>>
>> What I saw actually was like that:
>>
>> * Pros
>>
>> 1) It is a native ruby client
>> 2) We can import it in puppet and use all the power of Ruby
>> 3) We will not need to have a lot of forks/execs for puppet
>> 4) You are relying on negotiated and structured output provided by API
>> (JSON) instead of introducing workarounds for client output like [1]
>>
>> * Cons
>>
>> 1) Aviator is not actively supported
>> 2) Aviator does not track all the upstream OpenStack features while
>> native OpenStack client does support them
>> 3) Ruby community is not really interested in OpenStack (this one is
>> arguable, I think)
>>
>> * Proposed solution
>>
>> While I completely understand all the cons against using Aviator right
>> now, I see that Pros above are essential enough to change our mind and
>> invest our own resources into creating really good OpenStack binding in
>> Ruby.
>> Some are saying that there is not so big involvement of Ruby into
>> OpenStack. But we are actually working with Puppet/Ruby and are invloved
>> into community. So why should not we own this by ourselves and lead by
>> example here?
>>
>> I understand that many of you do already have a lot of things on their
>> plate and cannot or would not want to support things like additional
>> library when native OpenStack client is working reasonably well for you.
>> But if I propose the following scheme to get support of native Ruby
>> client for OpenStack:
>>
>> 1) we (community) have these resources (speaking of the company I am
>> working for, we at Mirantis have a set of guys who could be very
>> interested in working on Ruby client for OpenStack)
>> 2) we gradually improve Aviator code base up to the level that it
>> eliminates issues that are mentioned in  'Cons' section
>> 3) we introduce additional set of providers and allow users and
>> operators to pick whichever they want
>> 4) we leave OpenStackClient default one
>>
>> Would you support it and allow such code to be merged into upstream
>> puppet-openstack modules?
> 
> Hi,
> 
> I'm just throwing this out there since I didn't see it mentioned in
> either this thread or the linked one on the puppet-openstack ML, but ...
> 
> ... has anyone looked into fog (http://fog.io/ ) ?
> 
> 
> In my experience it generally works, and is updated fairly frequently.
> 
> 

Fog is an interesting and I think very exciting and ambitious project.

Meanwhile I'm not sure it could be a candidate to go along Net/HTTP or
Faraday because it's cloud generic, so quite high level, bringing many
things we don't need at all, unless we could use only the fog/openstack
part.


> 
> Regards,
> 
> 
> Tom
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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] [Horizon] unit test improvements: work with DOM, not raw HTML strings?

[Diana Whitten]

Richard,

I'm absolutely with you ... I've been bitten by these very tests recently
when changing a class in a simple template.  If anyone wants to override
these templates in the future, then they are forced to fight this
'expected_string' test as well.

I think this is a good idea.

- Diana

On Thu, Oct 22, 2015 at 3:52 PM, Richard Jones 
wrote:

> Hi all,
>
> I've noticed that we have quite a few places in our unit test suite that
> test for correctness of behaviour by searching for quite complex HTML
> fragments in page renders. An example would be
> openstack_dashboard/dashboards/project/access_and_security/floating_ips/tests.py
>
> (there's plenty more - search for "expected_string")
>
> The code in question is testing far more than it should. We are testing
> for the presence of the "disabled" class in an element which has a clear id
> attribute by constructing the whole element HTML, including label and title
> text, glyph icon, other classes, the tag type itself, etc. All of those
> things are quite irrelevant to the test in question, but any change to
> those will cause the test to break unnecessarily.
>
> In these cases a far more robust and targeted unit test would construct a
> DOM from the rendered HTML and use semantic searches to determine the
> correctness of behaviour. I would recommend we consider using something
> like https://django-with-asserts.rtfd.org/ which allow us to write:
>
>  with self.assertHTML(res, element_id='security_groups__action_create') as
> elem:
> self.assertContains(elem.attrib['class'], 'disabled')
>
> Who's with me?
>
>
> Richard
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] State of the Fuel gates: liftoff!

[Dmitry Borodaenko]

Back in July, I proposed a plan to implement PTI in Fuel [0] during Fuel
8.0 development cycle, with the following mandatory stages:

Stage 1: Create non-voting gate jobs for a single Fuel repo.
Stage 2: Get these gate jobs to pass and make them voting.
Stage 3: Create non-voting gate jobs for all Fuel repos.
Stage 4: Cover all Fuel repos with voting unit test gate jobs.

and bonus stages:

Stage 5: Add functional tests for Fuel UI and Fuel Library to the gates.
Stage 6: Run fuel-qa (multi-node deployment) tests on OpenStack Infra.

[0] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069908.html

With the Kilo based Fuel 7.0 released in September, we were finally able
to make some solid progress on that. Of 21 non-plugin Fuel repositories
on review.openstack.org, 12 (including one of our two largest core
components: fuel-web) already have voting gate jobs, 3 more (including 
the other largest core component: fuel-library) have passing gate jobs
that can become voting once all outstanding fixes are merged, and 3 more
are a work in progress.

Voting:
- fuel-agent
- fuel-dev-tools
- fuel-devops
- fuel-mirror
- fuel-octane
- fuel-ostf (pep8; python gates are waiting for images with gevent)
- fuel-plugins
- fuel-specs
- fuel-stats
- fuel-upgrade
- fuel-web
- python-fuelclient

Ready to vote:
- fuel-library (needs https://review.openstack.org/238628)
- fuel-menu
- shotgun

Work in progress:
- fuel-astute (has unit tests, needs a gate job)
- fuel-docs (docs gate job is failing)
- network-checker (unit test gate job is failing)

Not covered by unit tests:
- fuel-main (scripts to make Fuel ISO)
- fuel-nailgun-agent (588 lines of Ruby)
- fuel-qa (Fuel deployment system tests)

While it might be a bit too early to pull out a "Mission Accomplished"
banner, it's safe to say that vast majority of Fuel code is now covered
by gate checks running unit tests and syntax checks on OpenStack CI.

Nice work Alexey, Alex, Alexander, Sebastian, Vladimir, and Vladimir!
Many thanks to the OpenStack Infra team for encouraging and supporting
this effort!

-- 
Dmitry Borodaenko

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

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

[Oleg Gelbukh]

Hello,

We discussed this proposal in our team and came up with the following
vision of a configuration provisioning system:

- Installer is a system of multiple components: hardware inventory,
user interfaces, provisioning modules, deployment modules, checker modules,
volume manager, network manager, plugins, etc.
- Every component has its own data representation (we call them 'views'
as they provide an introspection in the configuration of the system), which
should include all the settings data the component should have access to to
perform its functions.
- Every component has 2 types of data in its view/representation:
authoritative data (which the component can modify) and external data
(which essentially is links to elements of another component's
view/representation).
- There is no 'universal' or 'general' representation of data which
serves a source of truth for all other views: every component is a source
of truth for its authoritative data.
- Views are defined as templates in some declarative language (YaML,
JSON, XML, %whatever%), think of jsonschema here. Authoritative settings of
the component have only type, external settings must also contain a link to
external view (might be just piece of code with properly referenced
elements of external view as parameters).
- View template shall be rendered in the data store during
'registration' of the component in the system, i.e. data structure shall be
created to represent the format of the data with necessary links.
- Views can be saved to the data store and modified by component that
'owns' the view's template, or via system's API. Changes to authoritative
settings in the view shall be propagated to all views that contain external
links to those settings.
- Both view template and views defined by it have versions. Template
version if defined by the version of it's owner component. View version
increases with every change made to it and can be used by the orchestrator
and component to determine if the async update of view was made by external
links.

We will continue to flesh it out as a specification in Fuel specs
repository. I will greatly appreciate any feedback on this vision,
including comments, objections, concerns and questions.

--
Best regards,
Oleg Gelbukh

On Tue, Oct 20, 2015 at 2:13 PM, Vladimir Kuklin 
wrote:

> Folks
>
> Can we please stop using etherpad and move to some more usable thing as
> Google Docs? Etherpad seems too unusable for such discussion especially
> with this coloured formatting.
>
> Mike
>
> I currently see no need in following marketing trend for noSQL here - we
> need to store a set of structured data. This store should be the one that
> can be easily consumed directly or with some API wrapper. That is all. We
> will need to carefully evaluate each storage engine and decide which to
> pick. I personally insist on the engine that provides 100% consistency
> which is in fact opposite to what most of noSQL and distributed
> architectures provide. Nobody cares if you lose 1 billion of messages in a
> social network (even these messages authors) - this is almost all the time
> garbage with porn and cat pictures. Things will get worse if you destroy
> something in production serving accounting in your cloud due to the fact
> that nodes are
>
> I agree with option #2 - we actually should have task abstraction layer
> with drivers for execution, but I would go with baby steps for supporting
> other deployment tools - currently I do not see any benefit in using
> Ansible for tasks that Fuel is solving. The same is almost true for
> containers, but this is a different story.
>
> Eugene, Mike
>
> I agree with you that we need to think about where to execute these
> serializers. I think that we could do it the following way - serializer can
> be executed wherever it can actually work and it should possibly put data
> into centralized storage for the means of logging, control and accounting.
> I am not sure that this is the limitation case all the users will agree
> with, but we need to think of it.
>
> Regarding this 'last task throwing an exception issue' - we can handle
> this properly by simply rerunning the task that failed only due to
> serialization problem. Or even better - reorder its execution for later
> steps and try it again in a while if there are other tasks to be executed.
>
> But Mike's approach of data preparation prior to deployment/workflow
> transaction execution seems more viable. I think, we should follow the
> following one: "If you do not know the data before the transaction run,
> this data should be calculated after this transaction ends and this data
> should be used for another workflow in a different transaction".
>
>
> On Tue, Oct 20, 2015 at 1:20 PM, Evgeniy L  wrote:
>
>> Hi,
>>
>> I have a comment regarding to when/where run translators.
>> I think data processing (fetching + validation + translation) should be
>> done
>> 

Re: [openstack-dev] [ironic] Next meeting is November 9

[Dmitry Tantsur]

On 10/22/2015 12:33 PM, Miles Gould wrote:

I've just joined - what is the usual place and time?


Hi and welcome!

All the information you need you can find here: 
https://wiki.openstack.org/wiki/Meetings/Ironic




Thanks,
Miles

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

Sent: Thursday, 22 October, 2015 8:33:03 AM
Subject: Re: [openstack-dev] [ironic] Next meeting is November 9

Hi Jim,

I will be on holiday the week of the 9th November and so will be unable to make 
that meeting. Work on the ironic UI will be posted in the sub team report 
section and if anyone has any questions regarding it please shoot me an email 
or ping me.

Thanks!
Beth


On 22 Oct 2015, at 01:58, Jim Rollenhagen  wrote:

Hi folks,

Since we'll all be at the summit next week, and presumably recovering
the following week, the next Ironic meeting will be on November 9, in
the usual place and time. See you there! :)

// jim

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


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

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




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

Re: [openstack-dev] [cross-project] Admin

[William M Edmonds]

Adam Young  wrote on 10/19/2015 09:53:14 AM:
> While I tend to play up  bug 968696 for dramatic effect, the reality is
> we have a logical contradiction on what we mean by 'admin' when talking
> about RBAC.
>
> In early iterations of OpenStack, roles were global.  This is reflected
> in many of the Policy checks that only look for the global role.
> However, prior to the Keystone-Light rewrite, role assignments became
> scoped to tenants.  This shows up in the Keystone git history.  As this
> pattern got established, some people wrote policy checks that assert:
>
>   role==admin and tenant_id=resource.tenant_id
>
> This contradicts the global-ness of the admin roles.  If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to
> perform all of the admin operations.
>
> Thus, today we have a situation where, unless the user rewrites the
> default policy, they have to only assign the role  admins to users that
> are trusted to be admins on the whole deployment.
>

This all appears to be based on a misassumptions that a) checking the
project id should be done in policy.json files and b) if it's not being
checked in the policy file then it's not being checked. Neither of those is
the case. Many APIs check project id in the code, which is where it should
be checked. Tokens are scoped to projects, thus any use of those tokens
should necessarily be scoped to the project... otherwise you're not obeying
the token scoping. The few places that are not already enforcing that in
their code need to be fixed to start enforcing that. It doesn't make sense
to do that in policy files, since this is a hard and fast rule, not
something someone needs to be able to change in policy, or should be able
to change. Nor would it be practical to put this in policy files when you
realize that this logic applies to all roles, not just admin.

-Matthew
__
OpenStack Development Mailing List (not for 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] Migration state machine proposal.

[Markus Zoeller]

Tang Chen  wrote on 10/21/2015 10:22:15 AM:

> From: Tang Chen 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/21/2015 10:24 AM
> Subject: Re: [openstack-dev] [Nova] Migration state machine proposal.
> 
> Hi,
> 
> Please help to take a look at this problem. I was trying to raise it in 
> the spec discussion.
> But since we don't need a spec on this problem, so I want to discuss it 
> here.
> It is about what the new state machine will be.
> 
> http://paste.openstack.org/show/476954/
> 
> Thanks.


I'd like to make you aware of bp "split-different-live-migration-types":
https://review.openstack.org/#/c/225910/
It intends to split those 3 types you are talking about. This could have
some overlap to your work.

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

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

[Vladimir Kuklin]

Oleg

Thank you for your feedback. IMO, the schema you are providing is very
complex and would surely benefit from some examples.

If I understand correctly your proposal, you are trying to do the things
that we actually want to get rid of - tight coupling and schema control of
data that is being used by components. There should be no cross-reference
between components that do actual deployment. Instead, there should be a
clear separation between layers of our deployment system.

All the data that is provided to deployment (or
provisioning/power_management/etc.) tasks should be accessible through API
of the top-level components such as
Network/Partitioning/IPAddressAllocation/ Manager or any other type of
external configuration database such as ENC of external puppet
master/LDAP/.

 Each task can use some code to transform this output to the representation
that is actually needed for this particular task. Whenever a task
transforms this data it can access API and do version negotiation, for
example. Each time this transformation is performed this task can return
the data to some storage that will save this data for sake of control and
troubleshooting, such as, for example, user can always see which changes
are going to be applied and decide what to do next.

Also, this means that the process of data calculation itself is very 'lazy'
or 'delayed', i. e. the data itself is calculated right at the beginning of
deployment transaction, so that it is not locked to some particular details
of deployment engine data processing and not prone to issues like 'oh, I
cannot get VIP because it has not been allocated yet by Nailgun/oh, I
cannot set it because it has already been set by Nailgun and there is no
way to alter it'.

On Thu, Oct 22, 2015 at 12:16 PM, Oleg Gelbukh 
wrote:

> Hello,
>
> We discussed this proposal in our team and came up with the following
> vision of a configuration provisioning system:
>
> - Installer is a system of multiple components: hardware inventory,
> user interfaces, provisioning modules, deployment modules, checker modules,
> volume manager, network manager, plugins, etc.
> - Every component has its own data representation (we call them
> 'views' as they provide an introspection in the configuration of the
> system), which should include all the settings data the component should
> have access to to perform its functions.
> - Every component has 2 types of data in its view/representation:
> authoritative data (which the component can modify) and external data
> (which essentially is links to elements of another component's
> view/representation).
> - There is no 'universal' or 'general' representation of data which
> serves a source of truth for all other views: every component is a source
> of truth for its authoritative data.
> - Views are defined as templates in some declarative language (YaML,
> JSON, XML, %whatever%), think of jsonschema here. Authoritative settings of
> the component have only type, external settings must also contain a link to
> external view (might be just piece of code with properly referenced
> elements of external view as parameters).
> - View template shall be rendered in the data store during
> 'registration' of the component in the system, i.e. data structure shall be
> created to represent the format of the data with necessary links.
> - Views can be saved to the data store and modified by component that
> 'owns' the view's template, or via system's API. Changes to authoritative
> settings in the view shall be propagated to all views that contain external
> links to those settings.
> - Both view template and views defined by it have versions. Template
> version if defined by the version of it's owner component. View version
> increases with every change made to it and can be used by the orchestrator
> and component to determine if the async update of view was made by external
> links.
>
> We will continue to flesh it out as a specification in Fuel specs
> repository. I will greatly appreciate any feedback on this vision,
> including comments, objections, concerns and questions.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Tue, Oct 20, 2015 at 2:13 PM, Vladimir Kuklin 
> wrote:
>
>> Folks
>>
>> Can we please stop using etherpad and move to some more usable thing as
>> Google Docs? Etherpad seems too unusable for such discussion especially
>> with this coloured formatting.
>>
>> Mike
>>
>> I currently see no need in following marketing trend for noSQL here - we
>> need to store a set of structured data. This store should be the one that
>> can be easily consumed directly or with some API wrapper. That is all. We
>> will need to carefully evaluate each storage engine and decide which to
>> pick. I personally insist on the engine that provides 100% consistency
>> which is in fact opposite to what most of noSQL and distributed
>> architectures provide. Nobody cares if you lose 1 

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

[Dmitriy Shulyak]

Hi Oleg,

I want to mention that we are using similar approach for deployment engine,
the difference is that we are working not with components, but with
deployment objects (it could be resources or tasks).
Right now all the data should be provided by user, but we are going to add
concept of managed resource, so that resource will be able to request data
from 3rd party service before execution, or by notification, if it is
supported.
I think this is similar to what Vladimir describes.

As for the components - i see how it can be useful, for example
provisioning service will require data from networking service, but i think
nailgun can act as router for such cases.
This way we will keep components simple and purely functional, and nailgun
will perform a role of a client which knows how to build interaction
between components.

So, as a summary i think this is 2 different problems.
__
OpenStack Development Mailing List (not for 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] HenryG addition to the Neutron Drivers team

[Rossella Sblendido]

Congratulations Henry! Well deserved!

On 10/21/2015 05:14 AM, Armando M. wrote:

Hi folks,

Henry has been instrumental in many areas of the projects and his crazy
working hours makes even Kevin and I bow in awe.

Jokes aside, I would like to announce HenryG as a new member of the
Neutron Drivers team.

Having a propension to attendance, and desire to review of RFEs puts you
on the right foot to join the group, whose members are rotated regularly
so that everyone is given the opportunity to grow, and no-one burns out.

The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
attend.

Please, join me in welcome Henry to the team.

Cheers,
Armando

[1]
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers



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



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

Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

[Anastasia Urlapova]

Simon,
my assumption about the file's[0] structure was incorrect, thank you for
review[1].
For fuel-qa fix was merged.

Nastya.
[0]https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
[1]https://review.openstack.org/#/c/238039/1

On Wed, Oct 21, 2015 at 10:18 PM, Mike Scherbakov 
wrote:

> We should fix it everyone. I don't think we need to be too heavy with the
> process, so I'd just update a single bug vs creating so many bugs...
>
> Fuel Infra team - please provide an estimate when script is going to be
> ready (which adds people automatically to gerrit review).
>
> Thanks,
>
> On Wed, Oct 21, 2015 at 6:04 AM Simon Pasquier 
> wrote:
>
>> Mike, thanks for the clarification!
>> I've filed a bug against fuel-qa [0] and submitted a patch [1]. Note that
>> after a quick look, many Fuel projects have the same issue with the format
>> of the MAINTAINERS file. Do you think we need one bug per project or do we
>> piggy-back on the fuel-qa bug?
>> BR,
>> Simon
>> [0] https://bugs.launchpad.net/fuel/+bug/1508449
>> [1] https://review.openstack.org/#/c/238039/
>>
>> On Wed, Oct 21, 2015 at 8:11 AM, Mike Scherbakov <
>> mscherba...@mirantis.com> wrote:
>>
>>> Nastya,
>>> according to the template I provided initially [1] format in fuel-qa is
>>> invalid. I've requested to support only one format [2].
>>> File must always have a folder. If you want to cover the whole repo,
>>> then the right structure would be
>>>
>>> maintainers:
>>>
>>>
>>> - ./:
>>>
>>> - name:   ...
>>>
>>>   email:  ...
>>>
>>>   IRC:...
>>> e.g. you'd just refer to the current folder, which should be root of the
>>> repo by default.
>>> Simon is asking a valid request: if you add his folder in the file, he
>>> will be always added to the review request by script, once it's
>>> implemented. Only in the case when contribution is made to his particular
>>> area of responsibility.
>>>
>>> [1] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
>>> [2] https://bugs.launchpad.net/fuel/+bug/1497655
>>>
>>> On Tue, Oct 20, 2015 at 11:03 PM Anastasia Urlapova <
>>> aurlap...@mirantis.com> wrote:
>>>
 Simon,
 structure of fuel-web repo is much more complex than fuel-qa, ~ 50
 active contributors work with fuel-web.
 There is the functionality of the different Fuel domains and each
 requires its own expertise, so maintenance is divided by folders.
 In case of fuel-qa maintainers are doing review for whole repository,
 structure of file[0] is correct.


 Nastya.
 [0] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS

 On Wed, Oct 21, 2015 at 2:15 AM, Mike Scherbakov <
 mscherba...@mirantis.com> wrote:

> Simon,
> I believe that it's a mistake in fuel-qa. Valid structure is in
> fuel-web. Please fix the one in fuel-qa.
>
> I'm also looking forward for automated adding of people to review
> requests based on this file. Here is the task to track it:
> https://bugs.launchpad.net/fuel/+bug/1497655
>
> On Tue, Oct 20, 2015 at 2:10 AM Simon Pasquier 
> wrote:
>
>> Thanks for the reply, Andrew! I must admit that I haven't read
>> thoroughly the specification on the new team structure [1]. IIUC plugin
>> developers should be added to the MAINTAINERS file of fuel-qa for the
>> directories that concern their plugins. If I take LMA as an example, this
>> would be:
>> fuelweb_test/tests/plugins/plugin_elasticsearch
>> fuelweb_test/tests/plugins/plugin_lma_collector
>> fuelweb_test/tests/plugins/plugin_lma_infra_alerting
>>
>> Is that right?
>>
>> I can submit a change to fuel-qa for adding the LMA team to the
>> MAINTAINERS file but I can't figure out the structure of the YAML data:
>> fuel-web/MAINTAINERS [2] is organized as "{directory1: [maintainer1,
>> maintainer2, ...], directory2: [...], ...}" while for fuel-qa [3] (and
>> other Fuel projects), it's "[maintainer1, maintainer2, ...]".
>>
>> BR,
>> Simon
>>
>> [1]
>> http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
>> [2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
>> [3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>>
>>
>> On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward 
>> wrote:
>>
>>> We have already discussed this to be a result of describing data
>>> driven testing, untill this spec is completed there is little sense to
>>> remove all of these since fuel-qa is 100% required to operate this way. 
>>> In
>>> the interim we should just specify the appropriate SME with the 
>>> MAINTAINERS
>>> file.
>>>
>>> On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <
>>> sgolovat...@mirantis.com> wrote:
>>>
 Tests should be in plugin

 --

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

[Oleg Gelbukh]

Hi Vladimir,

Thanks for prompt reply. Please, see my comments inline.

On Thu, Oct 22, 2015 at 12:44 PM, Vladimir Kuklin 
wrote:

> Oleg
>
> Thank you for your feedback. IMO, the schema you are providing is very
> complex and would surely benefit from some examples.
>

I'm going to submit spec for review that will incorporate examples and
diagrams for sure. I expect to come up with it in couple of days, most
likely by Monday.

>
> If I understand correctly your proposal, you are trying to do the things
> that we actually want to get rid of - tight coupling and schema control of
> data that is being used by components.
>

Your understanding is mostly correct. However, important thing here is that
we propose API that will allow to adjust schema of the particular view at
any time or register a new schema (for new/added component), etc, (almost)
without writing Python code.


> There should be no cross-reference between components that do actual
> deployment. Instead, there should be a clear separation between layers of
> our deployment system.
>

Such a separation will not be enforced by the system we propose. However,
if we indeed have some 'hierarchy' of components, it will be naturally
reflected in the way the links are specified in templates. For example, if
our primary source of configuration settings is UI/API, then it will be
authoritative for configurable parameters, like backends selection, IP
address ranges, etc. However, settings that are discovered from actual
nodes shall be provided by corresponding components, like 'nailgun-agent'.

Deployment modules most likely won't be authoritative for any settings, as
far as I can tell at the moment. They could, however, provide feedback-like
parameters, for instance, those that can be calculated only in runtime.


>
> All the data that is provided to deployment (or
> provisioning/power_management/etc.) tasks should be accessible through API
> of the top-level components such as
> Network/Partitioning/IPAddressAllocation/ Manager or any other type of
> external configuration database such as ENC of external puppet
> master/LDAP/.
>

This very proposal is about creating such an API (whether service-like or
library-like) that other components and even end users can leverage to
access and manage configuration parameters. We probably should start with
library API, and decide whether we need service of this kind later.


>
>  Each task can use some code to transform this output to the
> representation that is actually needed for this particular task. Whenever a
> task transforms this data it can access API and do version negotiation, for
> example. Each time this transformation is performed this task can return
> the data to some storage that will save this data for sake of control and
> troubleshooting, such as, for example, user can always see which changes
> are going to be applied and decide what to do next.
>
> Also, this means that the process of data calculation itself is very
> 'lazy' or 'delayed', i. e. the data itself is calculated right at the
> beginning of deployment transaction, so that it is not locked to some
> particular details of deployment engine data processing and not prone to
> issues like 'oh, I cannot get VIP because it has not been allocated yet by
> Nailgun/oh, I cannot set it because it has already been set by Nailgun and
> there is no way to alter it'.
>

To me, the two paragraphs above a contradictory. If the data calculations
are lazy, I don't really see how one can introspect into changes that will
be applied by a component at any given run. You just don't have this
information, and you need to calculate it anyways to see which settings
will be passed to a component. Might be I got your point wrong here. Please
correct me if this is the case.

Thanks again, looking forward to hear from you.

--
Best regards,
Oleg Gelbukh


>
> On Thu, Oct 22, 2015 at 12:16 PM, Oleg Gelbukh 
> wrote:
>
>> Hello,
>>
>> We discussed this proposal in our team and came up with the following
>> vision of a configuration provisioning system:
>>
>> - Installer is a system of multiple components: hardware inventory,
>> user interfaces, provisioning modules, deployment modules, checker modules,
>> volume manager, network manager, plugins, etc.
>> - Every component has its own data representation (we call them
>> 'views' as they provide an introspection in the configuration of the
>> system), which should include all the settings data the component should
>> have access to to perform its functions.
>> - Every component has 2 types of data in its view/representation:
>> authoritative data (which the component can modify) and external data
>> (which essentially is links to elements of another component's
>> view/representation).
>> - There is no 'universal' or 'general' representation of data which
>> serves a source of truth for all other views: every component is a source
>> of truth for its 

Re: [openstack-dev] [ironic] Next meeting is November 9

[Miles Gould]

I've just joined - what is the usual place and time?

Thanks,
Miles

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

Sent: Thursday, 22 October, 2015 8:33:03 AM
Subject: Re: [openstack-dev] [ironic] Next meeting is November 9

Hi Jim,

I will be on holiday the week of the 9th November and so will be unable to make 
that meeting. Work on the ironic UI will be posted in the sub team report 
section and if anyone has any questions regarding it please shoot me an email 
or ping me.

Thanks!
Beth

> On 22 Oct 2015, at 01:58, Jim Rollenhagen  wrote:
> 
> Hi folks,
> 
> Since we'll all be at the summit next week, and presumably recovering
> the following week, the next Ironic meeting will be on November 9, in
> the usual place and time. See you there! :)
> 
> // jim
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [cross-project] Admin

[Adam Young]

On 10/22/2015 05:16 AM, William M Edmonds wrote:


Adam Young  wrote on 10/19/2015 09:53:14 AM:
> While I tend to play up  bug 968696 for dramatic effect, the reality is
> we have a logical contradiction on what we mean by 'admin' when talking
> about RBAC.
>
> In early iterations of OpenStack, roles were global.  This is reflected
> in many of the Policy checks that only look for the global role.
> However, prior to the Keystone-Light rewrite, role assignments became
> scoped to tenants.  This shows up in the Keystone git history.  As this
> pattern got established, some people wrote policy checks that assert:
>
>   role==admin and tenant_id=resource.tenant_id
>
> This contradicts the global-ness of the admin roles.  If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to
> perform all of the admin operations.
>
> Thus, today we have a situation where, unless the user rewrites the
> default policy, they have to only assign the role  admins to users that
> are trusted to be admins on the whole deployment.
>

This all appears to be based on a misassumptions that a) checking the 
project id should be done in policy.json files and b) if it's not 
being checked in the policy file then it's not being checked. Neither 
of those is the case. Many APIs check project id in the code, which is 
where it should be checked. Tokens are scoped to projects, thus any 
use of those tokens should necessarily be scoped to the project... 
otherwise you're not obeying the token scoping. The few places that 
are not already enforcing that in their code need to be fixed to start 
enforcing that. It doesn't make sense to do that in policy files, 
since this is a hard and fast rule, not something someone needs to be 
able to change in policy, or should be able to change. Nor would it be 
practical to put this in policy files when you realize that this logic 
applies to all roles, not just admin.




I agree that project_id check is better performed in code.  That is not 
the issue here.


Checking Project ID needs to be done, policy file or code does not 
matter.  The problem is more fundamental.


0. All access is done with Keystone tokens.
1. Admin is a role assigned on a project. Always.
2. Some APIs have no project with which to check the Scope.
3. We do not, today, have a means to communicate the scope for an admin 
project.









-Matthew



__
OpenStack Development Mailing 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] [ANNOUNCE] [HA] new #openstack-ha IRC channel on FreeNode

[Adam Spiers]

Sorry!  It would have helped if I'd used the right address for the
openstack list in the To: and Reply-To: headers :-/

Hopefully second time lucky ...

Adam Spiers  wrote:
> [cross-posting to several lists; please trim the recipients list
> before replying!]
> 
> Hi all,
> 
> After discussion with members of the openstack-infra team, I
> registered new FreeNode IRC channel #openstack-ha.  Discussion on all
> aspects of OpenStack High Availability is welcome in this channel.
> Hopefully it will help promote cross-pollination of ideas and maybe
> even more convergence on upstream solutions.
> 
> I added it to https://wiki.openstack.org/wiki/IRC and also set up the
> gerritbot to auto-announce activity for the "new"
> openstack-resource-agents repository which I announced separately
> yesterday:
> 
>   http://lists.openstack.org/pipermail/openstack-dev/2015-October/077601.html
> 
> Still TODO: set up eavesdrop to record channel logs:
> 
>   https://review.openstack.org/#/c/237341/
> 
> Cheers,
> Adam

__
OpenStack Development Mailing 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] Horizon social meetup in Tokyo

[Akihiro Motoki]

Hi Horizon team,

Doug and I are planning a horizon social meetup in Tokyo.
As you may know, it is planned on Monday Oct 26.

10/26 20:00 -
Torikaku at Shinagawa Intercity (とりかく 品川インターシティ店)

The location is:
https://www.google.com/maps/place/Kineya+Shinagawa+Inter+City/@35.6269353,139.742403,15z/data=!4m2!3m1!1s0x0:0xf2d41438572bb73e!6m1!1e1
The location is the opposite side of Shinagawa Station from the Summit side.

It is located at B1F (a underground floor) of the "shop and restaurant
building" (between A and B buildings) at
http://www.sicity-sr.com/access.html
#31 of B1F floor http://www.sicity-sr.com/floorb.html (next to McDonald)

The entrance is like this (the middle picture)
http://www.hotpepper.jp/strJ04344/appearance/

If you have any trouble in reaching there, reach me @ritchey98 Twitter

The same information is available in
https://etherpad.openstack.org/p/horizon-mitaka-summit (around L.165)

See you in Tokyo!

Akihiro

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

Re: [openstack-dev] [ironic] Ironic design summit schedule

[Jim Rollenhagen]

On Thu, Oct 22, 2015 at 12:48:07AM -0700, Wan-yen Hsu wrote:
> Hi Jim,
> 
>   I have asked techtalk coordinator to switch my techtalk session time so
> there is no need to change group management session schedule.  You can keep
> it  at 2:50pm Wed.. Thanks!

Okay, I've now moved these back to the original schedule:

Wed 2:50-3:30 is Group management of servers
Thurs 11:00-11:40 is Driver API discussion

FWIW, your talk is still showing at 2:30-2:45 Wednesday on sched.org.

Sorry to all for the noise and confusion here.

// jim

> 
> 
> wanyen

> __
> OpenStack Development Mailing 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] [ANNOUNCE] [HA] new #openstack-ha IRC channel on FreeNode

[Adam Spiers]

[cross-posting to several lists; please trim the recipients list
before replying!]

Hi all,

After discussion with members of the openstack-infra team, I
registered new FreeNode IRC channel #openstack-ha.  Discussion on all
aspects of OpenStack High Availability is welcome in this channel.
Hopefully it will help promote cross-pollination of ideas and maybe
even more convergence on upstream solutions.

I added it to https://wiki.openstack.org/wiki/IRC and also set up the
gerritbot to auto-announce activity for the "new"
openstack-resource-agents repository which I announced separately
yesterday:

  http://lists.openstack.org/pipermail/openstack-dev/2015-October/077601.html

Still TODO: set up eavesdrop to record channel logs:

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

Cheers,
Adam

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

[openstack-dev] [Fuel] Bugs status for ui, python and library. And 'area-*' tags.

[Dmitry Pyzhov]

Guys,

1) Bugs status

Here is our current stats. Again I’ll show it in format “total (UI / python
/ library)"

Critical and high bugs: 52 (6/28/18). Last week it was 46 (1/23/22)
Medium, low and wishlist bugs: 196 (41/112/43). Last week it was 193
(47/104/42)
Features tracked as bug reports: 143. Last week we had 136. 111 are marked
with ‘feature’ tag and 32 covered by blueprints. Last week it was 143 in
total, 105 with 'feature' tag and 31 covered by blueprints.
Technical debt bugs: 106 (2/80/24). Last week it was 101 (1/77/23) in
total. Kinda huge and growing number. We’ve marked some of tech-debt bugs
as High because we think them pretty important. There are 10 (0/6/4). Last
week we had 9 (0/6/3)

Not so inspiring numbers this week. We work hard both on fixing and
reporting new bugs. It is about 15 new high priority defects reported every
week. This is why second topic of my e-mail is important.

2) Area tags
I'm analysing what's going on with our bugs and Launchpad is awful tool for
bugs management. I've added new 'area' tags to all bugs in 8.0 milestone.
You probably know it from Launchpad e-mail reports (:smile:). I've tried to
be as accurate as possible. We need these tags in order to measure our bugs
status precisely. I hope we will add these tags to our triage process next
week. Now you can try to use these tags and give some feedback if the idea
is useful or not. Later we'll work on making following filters reliable.

Python bugs: all

/open

(area-python tag)
Library bugs: all

/open

(area-library tag)
UI bugs: all

/open

(area-ui tag)
Octane bugs: all

/open

(area-octane tag)

Devops bugs: all

/open

(area-devops tag)
Fuel-ci bugs: all

/open

(area-ci tag)
Build bugs: all

Re: [openstack-dev] [heat] resource_registry base_url

[Angus Salkeld]

On Fri, Oct 23, 2015 at 8:10 AM Steve Baker  wrote:

> On 23/10/15 09:35, Jay Dobies wrote:
> > In looking through the environment file loading code, I keep seeing a
> > check for base_url in the resource registry. It looks like a way to
> > have the registry entries only be the filenames (I suppose relative
> > filenames work as well) instead of having to enter the full path every
> > time. The base_url would be used as the root URL for those filenames
> > when loading them.
> >
> > Thing is, I can't find any reference to that in the docs. I did a
> > search for resource_registry, but the only thing I can find is [1]
> > which doesn't talk about base_url.
>

Hi

I think the problem is, this is a heat client only feature. Meaning that the
docs for the API and service will not have any details of it.

There are other features in this boat too. I am not sure where the docs for
them
should live. I suspect in the heat client tree.


> >
> > Is this something that's still supported or was it "turned off" (so to
> > speak) by removing the docs about it so users didn't know to use it?
> > Is the syntax to just sit it side by side with the resource
> > definitions, similar to:
> >
> > resource_registry:
> >   "base_url": /home/jdob/my_templates
> >   "OS::Nova::Server": my_nova.yaml
> >
>

I think this is correct usage, tho' it's been ages since I wrote it and the
code has changed
heaps since then.

-Angus


> > Or am I just totally missing where in the docs it's talked about
> > (which is also terribly possible)?
> >
> > [1]
> >
> http://docs.openstack.org/developer/heat/template_guide/environment.html?highlight=resource_registry
> >
> > Thanks :)
>
> I'm not sure, since I've never used an explicit base_url. I just put the
> environment file which defines the resource_registry in the same
> directory as my_nova.yaml and the relative paths will resolve. Is that
> an option for you?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Integrating kollacli as python-kollaclient

[Swapnil Kulkarni]

On Thu, Oct 22, 2015 at 3:50 AM, Steven Dake (stdake) 
wrote:

> Hello Folks,
>
>
> Oracle has developed a CLI tool for managing OpenStack Kolla clusters.
> Several months ago at our midcycle, the topic was brought up an I suggested
> to go ahead and get started on the work.  We clearly didn't spend enough
> time discussing how it should be integrated into the code base or developed
> or even what its features should be, and that is my error.
>
>
> What ended up happening is sort of a code dump, which is not ideal, but I
> can only work so many 20 hour days ;)  I didn't believe our community had
> the bandwidth to deal with integrating a CLI directly into the tree while
> we were focused on our major objective of implementing Ansible deployment
> of OpenStack in Docker containers.  Possibly the wrong call, but it is what
> it is and it is my error, not Oracles.
>
>
> I think user experience will of the one of the major milestones for Kolla
in Mitaka, e.g. user facing documentation, operator integration etc. a CLI
would be helpful in that.

> The code can be cloned from:
>
> git clone git://oss.oracle.com/git/openstack-kollacli.git
>
>
> The code as is is very high quality but will likely need to go through
> alot of refactoring to ReST-ify it.  There are two major authors of the
> code, Borne Mace and Steve Noyes.
>
>
> I'd like a majority vote from the core team as to whether we should add
> this repository to our list of governed repositories in the OpenStack Kolla
> governance repository here:
>
>
>
> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L1509
>
>
> Consider this email a +1 vote from me.
>

+1 from me


> A completely separate email thread and decision will be made by the
> community about core team membership changes to handle maintenance of the
> code.  Assuming this code is voted into Kolla's governance, I plan to
> propose Borne as a core reviewer, which will be open to core team vote as a
> separate act with our 3 +1 votes no vetos within 1 week period.  We will
> address that assuming a majority vote of the code merge wins.  Steve can
> follow the normal processes for joining the core team if he wishes
> (reviewing patches) - clearly his code contributions are there.  Borne
> already does some reviews, and although he isn't a top reviewer, he does
> have some contribution in this area making it into the top 10 for the
> Liberty cycle.
>
>
>

> Kolla CLI Features:
>
>- dynamic ansible inventory manipulation via the host, group and
>service commands
>- ssh key push via the host setup command
>- ssh key validation via the host check command
>- ansible deployment via the deploy command
>- property viewing and modification with the property list, set and
>clear commands
>- cleanup of docker containers on a single, multiple or all hosts via
>the host destroy command
>- debug data collection via the dump command
>- configuration of openstack passwords via the password command
>- Lines of python = 2700
>- Lines of  test case code =  1800
>- ~ 200 commits
>
>
>
> __
> OpenStack Development Mailing 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] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Gilles Dubreuil]

On 21/10/15 00:56, Sofer Athlan-Guyot wrote:
> Gilles Dubreuil  writes:
> 
>> On 14/10/15 17:15, Gilles Dubreuil wrote:
>>>
>>>
>>> On 14/10/15 10:36, Colleen Murphy wrote:


 On Tue, Oct 13, 2015 at 6:13 AM, Vladimir Kuklin > wrote:

 Puppetmaster and Fuelers,

 Last week I mentioned that I would like to bring the theme of using
 native ruby OpenStack client and use it within the providers.

 Emilien told me that I had already been late and the decision was
 made that puppet-openstack decided to not work with Aviator based on
 [0]. I went through this thread and did not find any unresolvable
 issues with using Aviator in comparison with potential benefits it
 could have brought up.

 What I saw actually was like that:

 * Pros

 1) It is a native ruby client
 2) We can import it in puppet and use all the power of Ruby
 3) We will not need to have a lot of forks/execs for puppet 
 4) You are relying on negotiated and structured output provided by
 API (JSON) instead of introducing workarounds for client output like 
 [1]

 * Cons

 1) Aviator is not actively supported 
 2) Aviator does not track all the upstream OpenStack features while
 native OpenStack client does support them
 3) Ruby community is not really interested in OpenStack (this one is
 arguable, I think)

 * Proposed solution

 While I completely understand all the cons against using Aviator
 right now, I see that Pros above are essential enough to change our
 mind and invest our own resources into creating really good
 OpenStack binding in Ruby.
 Some are saying that there is not so big involvement of Ruby into
 OpenStack. But we are actually working with Puppet/Ruby and are
 invloved into community. So why should not we own this by ourselves
 and lead by example here?

 I understand that many of you do already have a lot of things on
 their plate and cannot or would not want to support things like
 additional library when native OpenStack client is working
 reasonably well for you. But if I propose the following scheme to
 get support of native Ruby client for OpenStack:

 1) we (community) have these resources (speaking of the company I am
 working for, we at Mirantis have a set of guys who could be very
 interested in working on Ruby client for OpenStack)
 2) we gradually improve Aviator code base up to the level that it
 eliminates issues that are mentioned in  'Cons' section
 3) we introduce additional set of providers and allow users and
 operators to pick whichever they want
 4) we leave OpenStackClient default one

 Would you support it and allow such code to be merged into upstream
 puppet-openstack modules?


 [0] 
 https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
 [1] 
 https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
 -- 
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04 
 +7 (926) 702-39-68 
 Skype kuklinvv
 35bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com 
 www.mirantis.ru 
 vkuk...@mirantis.com 


 The scale-tipping reason we went with python-openstackclient over the
 Aviator library was that at the same time we were trying to switch, we
 were also developing keystone v3 features and we could only get those
 features from python-openstackclient.

 For the first two pros you listed, I'm not convinced they're really
 pros. Puppet types and providers are actually extremely well-suited to
 shelling out to command-line clients. There are existing, documented
 puppet APIs to do it and we get automatic debug output with it. Nearly
 every existing type and provider does this. It is not well-suited to
 call out to other non-standard ruby libraries because they need to be
 added as a dependency somehow, and doing this is not well-established in
 puppet. There are basically two options to do this:

  1) Add a gem as a package resource and make sure the package resource
 is called before any of the openstack resources. I could see this
 working as an opt-in thing, but not as a 

Re: [openstack-dev] [Neutron][networking-sfc] no IRC project meeting for service function chaining project this week and next week

[Cathy Zhang]

Some key members of this project are either on business trip or on vacation 
after the Summit. So we will also cancel our IRC project meeting on 11/5 and 
resume the meeting on 11/12.

Thanks,
Cathy

From: Cathy Zhang
Sent: Wednesday, October 21, 2015 11:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][networking-sfc] no IRC project meeting for 
service function chaining project this week and next week

Hi,

Since most of us are very busy with presentation preparation for the Summit, 
let's cancel this week's project meeting.
We will resume the meeting on 11/5.

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] [kolla] Integrating kollacli as python-kollaclient

[Jastrzebski, Michal]

Hello,

I have looked at this code and it seems pretty solid. I'm not sure if it will 
be ready for governance as-is, there are few things I think have to be 
addressed before (for example I'm not sure if ansible can be dependency due to 
its license). Having said that I'd be happy to see it in our codebase as it 
will help kolla's user experience a lot.

So +1 from me, thanks guys for it!

Let's discuss what has to be done to get it into openstack asap, and then next 
steps. I'd like to volunteer to help you with that guys.

Regards,
Michał

> -Original Message-
> From: Paul Bourke [mailto:paul.bou...@oracle.com]
> Sent: Thursday, October 22, 2015 10:42 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [kolla] Integrating kollacli as 
> python-kollaclient
> 
> Having used the cli for some time I can vouch for it being very useful, and
> usable. The guys have done a nice job of giving it an "OpenStack feel",
> mimicking the patterns used in openstackclient and the like.
> 
> It should give users a more polished introduction to Kolla.
> 
> +1
> 
> -Paul
> 
> On 21/10/15 23:20, Steven Dake (stdake) wrote:
> > Hello Folks,
> >
> >
> > Oracle has developed a CLI tool for managing OpenStack Kolla clusters.
> > Several months ago at our midcycle, the topic was brought up an I
> > suggested to go ahead and get started on the work.  We clearly didn't
> > spend enough time discussing how it should be integrated into the code
> > base or developed or even what its features should be, and that is my error.
> >
> >
> > What ended up happening is sort of a code dump, which is not ideal,
> > but I can only work so many 20 hour days ;)  I didn't believe our
> > community had the bandwidth to deal with integrating a CLI directly
> > into the tree while we were focused on our major objective of
> > implementing Ansible deployment of OpenStack in Docker containers.
> > Possibly the wrong call, but it is what it is and it is my error, not 
> > Oracles.
> >
> >
> > The code can be cloned from:
> >
> > git clone git://oss.oracle.com/git/openstack-kollacli.git
> >
> >
> > The code as is is very high quality but will likely need to go through
> > alot of refactoring to ReST-ify it.  There are two major authors of
> > the code, Borne Mace and Steve Noyes.
> >
> >
> > I'd like a majority vote from the core team as to whether we should
> > add this repository to our list of governed repositories in the
> > OpenStack Kolla governance repository here:
> >
> >
> > https://github.com/openstack/governance/blob/master/reference/projects
> > .yaml#L1509
> >
> >
> > Consider this email a +1 vote from me.
> >
> >
> > A completely separate email thread and decision will be made by the
> > community about core team membership changes to handle maintenance of
> > the code.  Assuming this code is voted into Kolla's governance, I plan
> > to propose Borne as a core reviewer, which will be open to core team
> > vote as a separate act with our 3 +1 votes no vetos within 1 week
> > period.  We will address that assuming a majority vote of the code
> > merge wins.  Steve can follow the normal processes for joining the
> > core team if he wishes (reviewing patches) - clearly his code
> > contributions are there.  Borne already does some reviews, and
> > although he isn't a top reviewer, he does have some contribution in
> > this area making it into the top 10 for the Liberty cycle.
> >
> >
> >
> > Kolla CLI Features:
> >
> >   * dynamic ansible inventory manipulation via the host, group and
> > service commands
> >   * ssh key push via the host setup command
> >   * ssh key validation via the host check command
> >   * ansible deployment via the deploy command
> >   * property viewing and modification with the property list, set and
> > clear commands
> >   * cleanup of docker containers on a single, multiple or all hosts via
> > the host destroy command
> >   * debug data collection via the dump command
> >   * configuration of openstack passwords via the password command
> >   * Lines of python = 2700
> >   * Lines of  test case code =  1800
> >   * ~ 200 commits
> >
> >
> >
> >
> >
> 
> __
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Nova] Migration state machine proposal.

[John Garbutt]

On 22 October 2015 at 10:20, Nikola Đipanov  wrote:
> On 10/21/2015 10:17 PM, Joshua Harlow wrote:
>> Question on some things seen in the below paste.
>>
>> What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?
>>
>> Why does it jump over 'reverting' or 'confirming'? Should it?
>>
>> The other question is the difference between 'failed' and 'error' in the
>> first diagram, any idea on why/how these are semantically different? The
>> difference between 'done' and 'finished' are also in my mind
>> semantically confusing.
>>
>> Overall I'm very much inclined to have three state machines (one for
>> each type), vs the mix-mash of all three into one state machine (which
>> causes the confusion around states in the first diagram in that paste).
>>
>
> So the problem here is that they (as you point out) grew organically,
> and we are exposing these through the API. We need to keep them, and I
> see this BP as simply documenting them with automaton thrown in for it's
> validation and documenting features.

+1
That feels like step one.

> So - we _do not_ want to change these. Think of them as information for
> human consumption.
>
> What we may want to do is add an additional field (called state instead
> of status maybe), that we can use to re-boot states, and define better
> state machines that are easier to write tooling against. This is a
> separate effort, that will surely need a spec and a discussion to get
> the states right.

+1
Honestly, this feels very related to the Task related efforts.

Thanks,
John


>> Josh
>>
>> Tang Chen wrote:
>>> Hi,
>>>
>>> Please help to take a look at this problem. I was trying to raise it in
>>> the spec discussion.
>>> But since we don't need a spec on this problem, so I want to discuss it
>>> here.
>>> It is about what the new state machine will be.
>>>
>>> http://paste.openstack.org/show/476954/
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] Modularization activity POC

[Igor Kalnitsky]

Hey Evgeniy,

> if we drop containers, those will be just rpm/deb packages and
> dependencies between them

Despite the fact I'm a big fan of Docker and the ideas it brings to us
(build, ship & deploy fast), I'd prefer to go with RPM/DEB packages.
Simply because it would be easy to support and update.

> Regarding the spec our plan is to start writing spec after we have working 
> POC.

Do you have some working draft, at least?

Thanks,
Igor

On Wed, Oct 21, 2015 at 9:01 AM, Mike Scherbakov
 wrote:
> Thanks Eugene. I'd recommend to start integration as early as possible...
>
> On Tue, Oct 20, 2015 at 2:11 AM Evgeniy L  wrote:
>>
>> Hi Mike,
>>
>> 1. our plan is to have working partitioning/provisioning in a couple of
>> weeks,
>> networking is more complicated and it's better to ask Vladimir/Ryan.
>> 2, 3. here we have just some general ideas, we should have independent
>> releases on pypi,
>> each component should have responsible person (team), the same way we
>> do it for fuel-plugin-builder
>> and fuelclient. The same applies to independent docker containers.
>> Another thing is how
>> we are going to combine it in ready to use tool, there are several
>> ways, if we drop containers,
>> those will be just rpm/deb packages and dependencies between them, if
>> we continue using
>> docker containers, the simplest and the most robust way is to build a
>> single container which
>> has everything user needs.
>>
>> Regarding the spec our plan is to start writing spec after we have working
>> POC.
>>
>> Thanks,
>>
>>
>> On Tue, Oct 20, 2015 at 4:43 AM, Mike Scherbakov
>>  wrote:
>>>
>>> This is great start, Evgeny.
>>> I have a few questions:
>>>
>>> When do you expect to have POC to show?
>>> Do you plan to put new services into separate repos?
>>> How do you plan to package those - will you create RPM package for each,
>>> as well as Docker container (as we have everything in containers on Fuel
>>> master node)
>>>
>>> These questions, of course, should be covered in spec - so may be I
>>> should just wait for you guys to create specs. I just think that it's very
>>> important to think about integration from the very beginning.
>>>
>>> Thanks,
>>>
>>> On Mon, Oct 19, 2015 at 8:54 AM Igor Kalnitsky 
>>> wrote:

 Hey Evgeniy.

 This is awesome news1 I believe that microservices is way to go.
 Despite the fact that them bring a set of classical problems (e.g.
 duplication of domain entities) we will win more than loose. :)

 If there will be any specs or design meetings, please send me invite -
 I'd gladly join discussions.

 Thanks,
 Igor




 On Wed, Oct 14, 2015 at 5:30 PM, Evgeniy L  wrote:
 > Hi,
 >
 > We are starting Fuel modularization POC activity which is basically in
 > one
 > sentence
 > can be explained as "Use Fuel without Fuel", it means that we want to
 > provide
 > for a user a way to use some good things from Fuel, without entire
 > master
 > node and
 > other parts which user doesn't need.
 >
 > Currently we have monolithic system which includes every aspect of
 > deployment
 > logic, those components tightly coupled together, and there are few
 > persons
 > who understand all the interactions between components.
 >
 > As a result of modularization we will get the next benefits:
 > 1. reusability of components
 > 1.1. it will lead to more components consumers (users)
 > 1.2. better integration with the community (some community projects
 > might
 >be interested in using some parts of Fuel)
 > 2. components decoupling will lead to clear interfaces between
 > components
 > 2.1. so it will be easier to replace some component
 > 2.2. it will be easier to split the work between teams and it will
 > help
 > scale teams in
 >a much more efficient way
 >
 > Here are some thing which naturally can be used separately:
 > * network configuration (is a part of POC)
 > * advanced partitioning/provisioning (is a part of POC)
 > * discovery mechanism (ironic-inspector?)
 > * power management (ironic?)
 > * network verification
 > * diagnostic snapshot
 > * etc
 >
 > The main purpose of POC is to try to make partly working system to
 > figure
 > out the
 > scope of work which we will have to do upstream in order to make it
 > production ready.
 >
 > Here are few basic component-specific ideas:
 >
 > Advanced partitioning/provisioning
 > * split provisioning into two independent actions partitioning and
 > provisioning
 >   (currently we have a single call which does partitioning,
 > provisioning,
 >post provisioning configuration)
 > * figure out the data format 

[openstack-dev] [TripleO] Summit etherpads

[Dan Prince]

In case you haven't found this yet the TripleO etherpad locations are
all documented here:

https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#TripleO

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] [kolla] Liberty release builds

[Paul Bourke]

Ok so now liberty is tagged we can nail down the process here. Suggest 
we push first with latest, then when happy add the following tags:


* 1.0.0
* 1.0.0-liberty
* 1.0.0-liberty-release-001

===
git clone https://github.com/openstack/kolla
cd kolla
git checkout tags/1.0.0-liberty
tools/build.py \
--type source \
-- base < ... > \   # e.g. centos / ubuntu / oraclelinux / ...
--no-cache \
--push
===

Please respond with whether you're happy or not with the above. Would be 
nice to get images pushed before the summit.


Cheers,
-Paul

On 20/10/15 23:19, Steven Dake (stdake) wrote:



On 10/20/15, 9:06 AM, "Paul Bourke"  wrote:


Kolla core team,

Here's a link to an etherpad created just now for deciding the process
on getting release builds to dockerhub:

https://etherpad.openstack.org/p/kolla-release-builds

Please review and revise. Steve, can you follow up to this mail when
you'd like volunteers to kick off builds?


Paul,

Thanks for the initiative here!  We actually had one last minute patch
that needs to go into the tree related to Ceph failing to build
occasionally because of timers, so I decided to not push the tag until it
was resolved.  This was compounded by a node pool restart which broke
about 4 hours of CI testing of the patch that needs to go in to fix the
problem.

Once the release is tagged, we can go ahead and build for direct
consumption from the docker hub.

Regards,
-steve





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



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

Re: [openstack-dev] [release] establishing release liaisons for mitaka

[Kirill Zaitsev]

I’ve updated the page, and marked myself as a release liaison for Murano
(this is coordinated with Serg (sergmelikyan), Murano PTL).

Have already been closely watching release-tagged emails for some time.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 21 October 2015 at 22:48:24, Craig Vyvial (cp16...@gmail.com) wrote:

Doug,

I updated the liaisons for Trove on the wiki page. 

Thanks,
-Craig

On Wed, Oct 21, 2015 at 11:26 AM Doug Hellmann  wrote:
Excerpts from Lingxian Kong's message of 2015-10-21 16:42:32 +0800:
> Hi, Doug,
>
> After conversition with Mistral PTL(Renat), I'm willing to be mistral
> liaison to take participate in cross-project release effort on beharf
> of mistral team, so please count me in.

Great, thank you for volunteering!

Please add your contact details to the wiki page [3], and make sure
you have your email client configured so that you will see messages
with the "[release]" topic tag.

Doug

[3] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

>
> On Wed, Oct 14, 2015 at 11:25 PM, Doug Hellmann  wrote:
> > As with the other cross-project teams, the release management team
> > relies on liaisons from each project to be available for coordination of
> > work across all teams. It's the start of a new cycle, so it's time to
> > find those liaison volunteers.
> >
> > We are working on updating the release documentation as part of the
> > Project Team Guide. Release liaison responsibilities are documented in
> > [0], and we will update that page with more details over time.
> >
> > In the past we have defaulted to having the PTL act as liaison if no
> > alternate is specified, and we will continue to do that during Mitaka.
> > If you plan to delegate release work to a liaison, especially for
> > submitting release requests, please update the wiki [1] to provide their
> > contact information. If you plan to serve as your team's liaison, please
> > add your contact details to the page.
> >
> > Thanks,
> > Doug
> >
> > [0] 
> > http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons
> > [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Heat][Rant] About blank rechecks

[Jordan Pittier]

On Thu, Oct 22, 2015 at 9:58 AM, Thomas Herve  wrote:

> Hi all,
>
> You've seen me complain about people doing blank rechecks in Gerrit on
> IRC, and it seems it had little to no effect. So here I am trying to spread
> the word here. I'll try to stay calm.
>
> I'm seeing way too many rechecks on heat patches. It's not epidemic, but
> it's still enough to make me sad.
>
> First, it makes me sad as a developer. I don't know if it's just me, but
> one of the reason I code is curiosity, and debugging a gate failure is a
> great way to learn, pierce through the layers, and improve the situation.
>
> It then makes me sad as a team member. By doing a recheck you're basically
> implying that you don't care about the failure, and surely someone will
> care at some point. Except, the information will be lost, and we may have
> 100 builds before that happen again, when a release already happened, and
> we have to backport it. Working early means working less.
>
> And finally, it makes me sad for the infra team. Doing a recheck is
> disrespecting all the work they're doing to create a reliable environment
> to run our tests. Sure, sometimes the environment is the reason the failure
> happens, but then it's even more important to give feedback about it. They
> provide a great deal of logs, we can use logstach to find patterns, the
> least we can do is trying. We're also using resources that other projects
> could be using. As much as we'd like to believe it, the cloud doesn't have
> free infinite resources.
>
> Recently, I've seen many cases where rechecks were made whereas:
> 1) The heat branch was broken. Generally for some external reason (a
> dependency updated), doing a recheck is a pure waste of resources until
> that failure is fixed. Most of the time, we say something on IRC when it's
> the case. We also try to open a bug, so looking at launchpad can show
> something.
> 2) THE PATCH WAS ACTUALLY BROKEN. And there I'm not sad anymore I'm
> particularly angry. It basically means that you didn't look at all at the
> build results, and just mindlessly typed rechecks hoping that some fairy
> will fix your broken code. Frankly, that makes want to go on a -2 rampage.
> ESPECIALLY where a core is doing it.
>
> To close, I'll try to provide a solution. I know we all have our agenda,
> debugging gate failures takes some time that you may not have, and
> obviously "my patch is fine it's not my fault" (who cares, that's what
> being in a team means). Still, I'd like everyone to look at the test
> failures, look if the patch is not the problem, and if not open a bug [1]
> mentioning the test name, pasting the traceback in the description, and
> linking the build result. Then do recheck bug #xyz. That's it. It shouldn't
> take you more than 3 minutes, and at least we didn't lose the information.
>
> Thanks for reading that far and sorry for the length,
>
>
> [1] https://bugs.launchpad.net/heat/+filebug
>
> --
> Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Hi Thomas,
I hear you and I have the exact same feeling on the projects I am involved
in.


Testing and our CI is the root of OpenStack's product quality, it deserves
care, attention, involvement from everybody.


I take the opportunity of this email to put a link to our logstash here
http://logstash.openstack.org/ and to our Elasticrecheck project here
http://status.openstack.org/elastic-recheck/ (I only learnt about this
tools a few month ago and I think they bring a lot of value)

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

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Dmitry Ilyin]

I have investigated this issue too.

Previously, Puppet "commands" had only stdout in their output value and
stderr was discarded unless the command have returned an error code and the
exception is raised with stderr as its message.
In the current Puppet versions BOTH stdout and stderr go into the comamnd
output. It's bad in out case because it breaks neutron command output
parsing and can impact any other command.

2015-10-22 14:50 GMT+03:00 Martin Mágr :

>
>
> On 10/22/2015 05:16 AM, Matt Fischer wrote:
>
>> I thought we had code in other places that split out stderr and only
>> logged it if there was an actual error but I cannot find the reference now.
>>
>
> https://github.com/openstack/puppet-glance/blob/stable/kilo/lib/puppet/provider/glance.rb#L184
>
> But it was removed in master branch for some reason.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Matt Fischer]

On Thu, Oct 22, 2015 at 12:52 AM, Sergey Vasilenko 
wrote:

>
> On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer 
> wrote:
>
>> I thought we had code in other places that split out stderr and only
>> logged it if there was an actual error but I cannot find the reference now.
>> I think that matches the original proposal. Not sure I like idea #3.
>
>
> Matthew, this topic not about SSL. ANY warnings, ANY output to stderr from
> CLI may corrupt work of providers from puppet-* modules for openstack
> components.
>
> IMHO it's a very serious bug, that potential affect openstack puppet
> modules.
>
> I see 3 way for fix it:
>
>1. Long way. big patch to puppet core for add ability to collect
>stderr and stdout separately. But most of existing puppet providers waits
>that stderr and stdout was mixed when handle errors of execution (non-zero
>return code). Such patch will broke backward compatibility, if will be
>enabled by default.
>2. Middle way. We should write code for redefine 'commands' method.
>New commands should collect stderr and stdout separately, but if error
>happens return stderr (with ability access to stdout too).
>3. Short way. Modify existing providers to use json output instead
>plain-text or csv. JSON output may be separated from any garbage (warnings)
>slightly. I make this patch as example of this way:
>https://review.openstack.org/#/c/238156/ . Anyway json more formalized
>format for data exchange, than plain text.
>
> IMHO way #1 is a best solution, but not easy.
>
>
I must confess that I'm a bit confused about this. It wasn't a secret that
we're calling out to commands and parsing the output. It's been discussed
over and over on this list as recently as last week, so this has been a
known possible issue for quite a long time. In my original email I was
agreeing with you, so I'm not sure why we're arguing now. Anyway...

I think we need to split stderr and stdout and log stderr on errors, your
idea #2. Using json like openstack-client can do does not solve this
problem for us, you still can end up with a bunch of junk on stderr.

This would be a good quick discussion in Tokyo if you guys will be there.
__
OpenStack Development Mailing 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] [Horizon] Horizon social meetup in Tokyo

[Akihiro Motoki]

I resent my mail as I forgot to add [Horizon] tag.

2015-10-22 23:50 GMT+09:00 Akihiro Motoki :
> Hi Horizon team,
>
> Doug and I are planning a horizon social meetup in Tokyo.
> As you may know, it is planned on Monday Oct 26.
>
> 10/26 20:00 -
> Torikaku at Shinagawa Intercity (とりかく 品川インターシティ店)
>
> The location is:
> https://www.google.com/maps/place/Kineya+Shinagawa+Inter+City/@35.6269353,139.742403,15z/data=!4m2!3m1!1s0x0:0xf2d41438572bb73e!6m1!1e1
> The location is the opposite side of Shinagawa Station from the Summit side.
>
> It is located at B1F (a underground floor) of the "shop and restaurant
> building" (between A and B buildings) at
> http://www.sicity-sr.com/access.html
> #31 of B1F floor http://www.sicity-sr.com/floorb.html (next to McDonald)
>
> The entrance is like this (the middle picture)
> http://www.hotpepper.jp/strJ04344/appearance/
>
> If you have any trouble in reaching there, reach me @ritchey98 Twitter
>
> The same information is available in
> https://etherpad.openstack.org/p/horizon-mitaka-summit (around L.165)
>
> See you in Tokyo!
>
> Akihiro

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

Re: [openstack-dev] [neutron][sriov] SRIOV-VM could not work well with normal VM

[Armando M.]

On 22 October 2015 at 01:21, yujie  wrote:

> I used ixgbe and vlan, passthrough a VF to vm.
> After the VM created, it could not connect to VM on the same compute node
> without use sriov.
>
>
Not sure if this is the same conversation happening on Launchpad, but if
not, this might be relevant:

https://bugs.launchpad.net/neutron/+bug/1506003


> 在 2015/10/22 10:58, Alexander Duyck 写道:
>
>> I assume by Intel cards you mean something that is running ixgbe?  If so
>> and you are trying to use SR-IOV with OVS and VLANs running on top of
>> the PF it will fail. The issue is that OVS requires the ability to place
>> the PF in promiscuous mode to support VLAN trunking, and ixgbe driver
>> prevents that when SR-IOV is enabled.
>>
>> The "bridge fdb add" approach mentioned should work as long as ixgbe PF
>> is used on a flat network.
>>
>> - Alex
>>
>> On 10/19/2015 07:33 PM, yujie wrote:
>>
>>> Hi Moshe Levi,
>>>Sorry for replying to this message after so long time. The testing
>>> environment was unavailable before.
>>>I use Intel cards, but could only tested base kilo and vlan. Could
>>> it work?
>>>
>>> 在 2015/9/22 13:24, Moshe Levi 写道:
>>>
 Hi Yujie,

 There is a patch https://review.openstack.org/#/c/198736/ which I
 wrote to add the mac of the normal instance to
 the SR-IOV embedded switch so that the packet will go to the PF
 instead of going to the wire.
 This is done by using bridge tool with the command "bridge fdb add
  dev "

 I was able to test it on Mellanox ConnectX3  card with both vlan and
 flat network and it worked fine.
 I wasn't able to test it on any of the Intel cards, but I was told
 the it only working on flat network, in vlan network the Intel card
 is dropping the tagged packets and they are not go up to the VF.

 What NIC are you using? Can you try using "bridge fdb add  dev
 " where  is the mac of the normal vm and 
 is the PF
 and see if  that resolve the issue.
 Also can you check it with  flat and vlan networks.


 -Original Message-
 From: yujie [mailto:judy_yu...@126.com]
 Sent: Tuesday, September 22, 2015 6:28 AM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [neutron][sriov] SRIOV-VM could not work
 well with normal VM

 Hi all,
 I am using neutron kilo without dvr to create sriov instance VM-A,it
 works well and could connect to its gateway fine.
 But when I let the normal instance VM-B which in the same
 compute-node with VM-A ping its gateway, it failed. I capture the
 packet on the network-node, find the gateway already reply the
 ARP-reply message to VM-B. But compute-node which VM-B lives could
 not send the package to VM-B.
 If delete VM-A and set : echo 0 >
 /sys/class/enp5s0f0/device/sriov_numvfs, the problem solved.

 Is it a same question with the bug: SR-IOV port doesn't reach OVS
 port on same compute node ?
 https://bugs.launchpad.net/neutron/+bug/1492228
 Any suggestions will be grateful.

 Thanks,
 Yujie



 __

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


 __

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


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

[Armando M.]

Hi folks,

We currently have the submissions and only 6 slots. There's still some time
left before the end of this week.

Whoever put an entry in the etherpad [1], please consider adding your name,
otherwise we don't know who to reach out during the session [2]. If all
things stay the same, we'll pick the 6 ones that have a name assigned to
them.

Cheers,
Armando


   - Results presentation for the Nova Networks/Nuetron migration survey.
   (piet)


   - Dragonflow, Liberty release and beyond - gsagie


   - DSCP QoS implementation - njohnston, vhoward


   - Adding BGP EVPN Support to BGP Dynamic Routing, for Dynamic Separation
   of Internet andTenant External Traffic - mickeys


   - BGP dynamic routing status


   - BGPVPN project status


   - L2GW as inter-cloud connectivity entity (boarder gateway) - gsagie


[1] https://etherpad.openstack.org/p/mitaka-neutron-labs-lighting-talks
[2]
http://mitakadesignsummit.sched.org/event/2233580b895bc50617a06d7795d8e562#.VikNMmSrR-U
__
OpenStack Development Mailing 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] [QA] No Meeting until Nov. 12th

[Matthew Treinish]

Hi everyone,

Just realized I never sent out the reminder that we won't be holding our weekly
meetings until after summit. Since people are travelling this week we won't be
having the meeting today either.

Our normal weekly meeting schedule will resume on Nov 12th. The time for the
meeting that week will be 0900 UTC.

Thanks,

-Matt Treinish


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] [api][ironic] some questions about tags

[Ryan Brown]

On 10/21/2015 11:14 PM, Tan, Lin wrote:

Hi guys,

Ironic is implementing the tags stuff:
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/nodes-tagging,n,z

And this work is follow the guidelines of API Workgroup:
http://specs.openstack.org/openstack/api-wg/guidelines/tags.html

But I have two doubts about the guideline:
1. Can we support partial update the Tag List using PATCH. I see there is an 
option to add/delete individual tag, but it is still using PUT. What's the 
disadvantage here for PATCH?


The major disadvantage of PATCH is that there isn't an official standard 
for partial representation of things like lists. There are things like 
JSONPatch[1] that provide guidance, but since OpenStack hasn't really 
made a choice, we haven't put up a guideline.


For information on what we *have* done regarding PATCH, see the HTTP 
Methods guide[2].



2. Can we update the tag as well? For example, in Gmail we can rename the label 
if necessary, which is much more friendly to me. But currently, this is not 
support from the guide. The only way to support this is cached the tags's 
entities and retag them in python client, I don't think it's a good way.


The idea behind our guideline is to specify the way the API should allow 
users to access the tags on their resources. You can (of course!) extend 
functionality and add the ability to rename tags if you'd like.


If you were to use PATCH, then renaming a tag could look like:

step 1: get servers with tag X
step 2: PATCH
  [
{"op": "replace", "path": "/tags/1", "value": "Y"}
  ]

That would replace the existing tag with the new one, if you were using 
JSONPatch.



Best Regards,

Tan


1: http://jsonpatch.com/
2: 
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods

--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

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

Re: [openstack-dev] [tc] [watcher] New project: Watcher

[Antoine Cabot]

On Wed, Oct 21, 2015 at 3:38 PM, gord chung  wrote:

> hi,
>
hi

>
> seems like a neat idea, i had a few questions after watching the
> presentation from Vancouver.
>
thanks for your interest in Watcher

>
> - is Watcher streaming the data captured by Ceilometer or is it querying
> the Ceilometer db?
>
Watcher can stream data captured by Ceilometer. Regarding the Ceilometer
db, we had performance issues when querying the database so we decided to
use streamed data instead.

> - is it utilising the Event data captured by Ceilometer or metric data?
> both?
>
actually watcher can do both as we capture the data stream

> - i notice there's a tsdb used by Watcher. what TSDB is supported?
>
today we are supporting InfluxDB and we plan to add OpenTSDB in the coming
months

> - is alarming functionality provided by Aodh used or is the 'machine
> learning'+'orchestration' service meant to replace the functionality
> provided by Aodh+Heat?
>
no we do not use this functionality today but we should definitely discuss
about it

>
> one reason i'm asking is that Ceilometer has a section in wiki to list
> projects that leverage Ceilometer[1] so it's easy to track existing
> extensions. feel free to add Watcher there if you feel like it.
>
I will do it, thank you

>
> [1] https://wiki.openstack.org/wiki/Ceilometer#Ceilometer_Extensions
>
> If you want to go deeper into Watcher architecture, feel free to join our
community meetup at 10:45am on tuesday [2]


> cheers,

cheers,

[2]  https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads

>
> On 21/10/2015 8:22 AM, Antoine CABOT wrote:
>
>> We are pleased to introduce Watcher, a new project in the OpenStack
>> ecosystem. We believe that a "resource optimization" service in an
>> OpenStack-based cloud is a crucial component that has been missing to
>> date and we have started working towards filling that gap.
>>
>> OpenStack Watcher provides a flexible and scalable resource
>> optimization service for multi-tenant OpenStack-based clouds.
>> Watcher provides a complete optimization loop—including everything
>> from a metrics receiver, complex event processor and profiler,
>> optimization processor and an action plan applier. This provides a
>> robust framework to realize a wide range of cloud optimization goals,
>> including the reduction of data center operating costs, increased
>> system performance via intelligent virtual machine migration,
>> increased energy efficiency—and more!
>>
>> Not only does Watcher provide several out-of-box optimization routines
>> for immediate value-add, but it also supports a pluggable
>> architecture by which custom optimization algorithms, data metrics and
>> data profilers can be developed and inserted into the Watcher framework.
>> Additionally, Watcher enables two different modes of execution—advise
>> mode (manual) or active mode (automatic), giving cloud administrators
>> the runtime flexibilities that their clouds require. Most importantly,
>> administrators of OpenStack-based clouds equipped with Watcher will
>> decrease their Total Cost of Ownership (TCO) by way of more efficient
>> use of their infrastructure and less “hands on” (read: manual)
>> administrator involvement to perform optimizations.
>>
>> More information, including key use cases, architecture, etc., are
>> described on the project wiki [0].  Also feel free to browse some
>> source code [1, 2].
>>
>> We meet weekly on Wednesdays at 16:00 UTC in the #openstack-meeting-3
>> IRC channel. You can also use #openstack-watcher to contact the team.
>>
>> We hope to see you at our unconference session at the upcoming
>> OpenStack Summit in Tokyo and we are welcoming participation from the
>> community.  Let us know if you are interested in this topic and
>> join us in #openstack-watcher!
>>
>> Regards,
>>
>> Antoine Cabot (Watcher PTL) (acabot)
>> Susanne Balle (sballe)
>> Joe Cropper (jwcroppe)
>>
>> [0] https://wiki.openstack.org/wiki/Watcher
>> [1] https://github.com/openstack/watcher
>> [2] https://github.com/openstack/python-watcherclient
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> --
> gord
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Assigning VIPs on network config serialization

[Igor Kalnitsky]

Hi all,

Let's summarize what we have by now.

1/ We agreed on removing *VIP allocation* code from GET
network_configuration API handler. Already allocated VIPs should be
returned by this call though.
2/ We agreed on checking whether it's enough IP addressed in the pool
as a part of Verify Network API call (currently we do it only in
before deployment checks).
3/ We should keep in mind (and perhaps make some ticket) about ability
to allocate VIPs on demand.. on some API call, or even be able to
assign custom one.

I think we need update LP ticket of (1), and file a ticket for (2).

Sounds like a plan, ha?

Thanks,
Igor

On Wed, Oct 21, 2015 at 3:54 PM, Aleksey Kasatkin
 wrote:
>> Then we should close [1] as invalid, shoudn’t we?
>
> AFAIC, no. We should check whether there is enough IPs for nodes /
> VIPs with current network configuration.
>
> I'd propose to add a handler for allocation of VIPs if VIPs can be useful
> before deployment.
> I'm not sure what are the cases.
>
>
>
> Aleksey Kasatkin
>
>
> On Wed, Oct 21, 2015 at 11:45 AM, Roman Prykhodchenko  wrote:
>>
>> Then we should close [1] as invalid, shoudn’t we?
>>
>> > 20 жовт. 2015 р. о 15:55 Igor Kalnitsky 
>> > написав(ла):
>> >
>> > Roman,
>> >
>> >> This behavior is actually described in [1]. Should we allocate
>> >> VIPs on network check as well?
>> >
>> > No, we shouldn't. We should check whether it's enough IPs for nodes /
>> > VIPs with current network configuration, but no more.
>> >
>> > - igor
>> >
>> > On Tue, Oct 20, 2015 at 4:54 PM, Igor Kalnitsky
>> >  wrote:
>> >> Andrew,
>> >>
>> >>> but the problem lies that VIP's need to already be allocated.
>> >>
>> >> Why? Fuel doesn't use them on this stage.
>> >>
>> >>
>> >>> They need to be allocated on network update, or when a node role
>> >>> requiring
>> >>> one is added to the environment.
>> >>
>> >> It looks like either you or me misunderstood something. AFAIK, node
>> >> role itself has nothing in common with VIPs. It doesn't require any of
>> >> them.
>> >>
>> >> Currently VIPs are requested by network roles, and network roles are
>> >> the same for all nodes (except Network Templating case). Network roles
>> >> are assigned on network, and if VIP is required for network role it
>> >> will be allocated in the assigned network.
>> >>
>> >> So basically, it requires a huge effort to redesign our allocation
>> >> system to achieve what you want, because:
>> >>
>> >> * Each time you reassign network role, the corresponding VIP should be
>> >> re-allocated in the database either.
>> >> * Each time you enable/disable plugins, the VIPs should be
>> >> re-allocated, because plugins may export network roles.
>> >> * Each time you add new node to cluster, the VIPs should be
>> >> re-allocated, because with new node you simply may run out of free
>> >> IPs. And, btw, should we assign IP on added nodes here? Or maybe
>> >> postpone to serialization step?
>> >>
>> >> Well, Andrew, I believe we don't have enough resources to implement
>> >> your proposal. Moreover, the proposed approach requires a lot of
>> >> discussions and design meetings. And it definitely should be
>> >> implemented in scope of some blueprint, not a bugfix.
>> >>
>> >>
>> >>> Not knowing the address until serialization for deployment is too
>> >>> late.
>> >>
>> >> Once again - why? I agree, perhaps it would be useful, but there's no
>> >> strict requirement on this and we should resolve our issues
>> >> step-by-step. See my response above.
>> >>
>> >>
>> >>> No, Again, this is too late.
>> >>
>> >> Too late for what?
>> >>
>> >>
>> >> - Igor
>> >>
>> >> On Tue, Oct 20, 2015 at 12:38 PM, Roman Prykhodchenko 
>> >> wrote:
>> >>> My concern here is that there is also a Network check feature that
>> >>> according to its name should check things like whether or not there’s 
>> >>> enough
>> >>> IP addresses in all ranges in a network. The problem is that it may be 
>> >>> run
>> >>> at any time, even when VIPs are not yet allocated. From a user-side the
>> >>> workflow may look a little wrong:
>> >>>
>> >>> 1. Check network => get "Everything is fine"
>> >>> 2. Right after that press Apply Changes => get "Network configuration
>> >>> is bad"
>> >>>
>> >>> This behavior is actually described in [1]. Should we allocate VIPs on
>> >>> network check as well?
>> >>>
>> >>>
>> >>> 1. https://bugs.launchpad.net/fuel/+bug/1487996
>> >>>
>> >>>
>> >>> - romcheg
>> >>>
>> >>>
>>  19 жовт. 2015 р. о 18:28 Igor Kalnitsky 
>>  написав(ла):
>> 
>>  Hi Roman,
>> 
>> > Not assign addresses to VIPs is a network configuration is being
>> > serialized for API output.
>> 
>>  AFAIK, that's not truth. Fuel UI and OSTF relies only on *public*
>>  VIP.
>>  So we can keep only *public* VIP, and do not assign / show others.
>> 
>> > Check number of IP addresses wherever