Re: [openstack-dev] [neutron][stable] proactive backporting

[Ihar Hrachyshka]

> On 17 Oct 2015, at 00:26, Armando M.  wrote:
> 
> I am pretty confident that the experience you went through was an exception 
> rather than the rule. We're pretty flexible and allow a patch to go in 
> (master) with a promise of a follow up, if it's critical backport. The 
> important thing is to identify that...and this is what Ihar is talking about 
> in this thread.
> 
> It is noteworthy that 'trail blazing' as you say makes the patch difficult to 
> backport, so any advice given in this direction was clearly pointing you the 
> wrong way.
> 

If we talk about nitpicking for backports, I am not sure it’s indeed anything 
but an exception and a reviewer mistake that should be pointed out and ignored 
instead of being handled. (I seldom need to request a revert to the original 
‘bad’ version of a patch when I see such ‘enhancements' before I allow a patch 
in.)

It’s herd wisdom in openstack that backports must not differ from their 
original master counterparts, unless there is actual need for it (like gate 
failure, test framework differences, etc.) Apart from it, any nitpicking about 
tests, typos, import order, incorrect copyright year, etc. is out of place in 
stable branches. If you get a suggestion to ‘enhance’ your backport in some way 
that is of no user visible influence, kindly suggest the reviewer to fix it in 
master and backport to stable branches, if they care that much. It’s not your 
job to fix it. The only exception is if by chance backport review reveals an 
actual bug in master code that would introduce a regression in stable branches, 
if backported. In that case, the backport should be blocked until master is 
fixed and the second backport is proposed; in that case, both backports should 
be up for review and ready to merge before the first one is pushed into gate 
(that’s to ensure we reduce chance of breaking someone who catches up with the 
branch in the middle).

I thought it’s documented and/or self-obvious, but since probably it’s not, I 
updated the stable branch guidelines as per above:

https://wiki.openstack.org/wiki/StableBranch#Proposing_Fixes

Now, that was only for backports. But as for master, I agree with other folks 
that expressed the need for decent test coverage before a patch is considered 
for master merge, even for major issues. It’s better to spend some time on 
polishing tests and enhancing test coverage (and becoming assured that the fix 
is correct and does not break anything), then to push a patch in and hope for 
the best, waiting until our users hit a regression that is caused by 
insufficient test coverage.

Now, that does not mean that we should postpone critical patches due to 
incomplete test framework that would require months to get into shape; that 
said, for non-critical patches, it may be reasonable to push committers a bit 
harder to get to the point when we have testing framework deficiencies closed, 
and where we feel more safe to touch the code that (apart from the bug in 
question) seems to work.

Again, if we plan to backport a fix into stable branches, it’s ok to have 
enhanced testing coverage made as a follow-up, when otherwise we would have 
issues with backporting the tests to stable branches. Actually, thanks to 
Armando’s polishing our policies, we already have that caution documented:

http://docs.openstack.org/developer/neutron/devref/effective_neutron.html#scoping-your-patch-appropriately

Quoting: "If a fix or feature requires code refactoring, submit the refactoring 
as a separate patch than the one that changes the logic. Otherwise it’s 
difficult for a reviewer to tell the difference between mistakes in the 
refactor and changes required for the fix/feature. If it’s a bug fix, try to 
implement the fix before the refactor to avoid making cherry-picks to stable 
branches difficult.”

Feel free to use the quote when pushing for a high priority bug fix in master. 
(Note that while it allows a follow up, it does not explicitly suggest that 
follow up can be up for review after the actual bug fix is merged; but the 
logic and common sense suggest that in some critical cases it can be the case, 
assuming there is at least some test coverage for the code touched, even if not 
ideal.)

Ihar


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

Re: [openstack-dev] [neutron][stable] proactive backporting

[Ihar Hrachyshka]

> On 16 Oct 2015, at 23:04, Edgar Magana  wrote:
> 
> + 2 and total support for it.
> 
> Looking forward to reviewing the first set of them.

If we talk about actual backports on review, they are always there. I suggest 
folks that are interested in stable branches to use the Kyle’s dashboard: 
https://github.com/openstack/gerrit-dash-creator/blob/master/dashboards/neutron-subprojects-stable.dash
 and have the link produced by the tool in their favorites.

Ihar


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

Re: [openstack-dev] [neutron][stable] proactive backporting

[Ihar Hrachyshka]

> On 16 Oct 2015, at 19:09, Sean M. Collins  wrote:
> 
> On Fri, Oct 16, 2015 at 11:36:13AM EDT, Salvatore Orlando wrote:
>> It might also make sense to ask contributors to resume the habit of tagging
>> bugs with 'backport-potential' even if not in the RC period.
> 
> I like this idea because it'll make Ihar's job easier :)


Kind of you Sean. ;) That said, we are not here to make my job easier but to 
make our product better.

Another point I want to make is that the original plan is described in terms of 
me doing the initial triage. I don’t want to suggest that I am the eternal one 
to do it. No, I am not suicidal, but buses drive nearby, so I would be glad if 
someone tries to take on it once in a while. ;)

Another point to consider is that backport proposers do not have +2 for their 
own backports (well technically they do but it’s countradictory to openstack 
guidelines). Since I am one of the folks who have +2 in neutron stable stadium, 
it could be wise to allow someone without the hammer to propose backports and 
me spending my vote on them. So if folks out of formal neutron-stable-maint 
group will join the effort, it will be better for everyone, but especially 
stable branch chasers.

Ihar


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

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[Renat Akhmerov]

> On 19 Oct 2015, at 07:53, WANG, Ming Hao (Tony T) 
>  wrote:
> 
> The “custom action” needs to re-install Mistral.
> If the Mistral service is part of 3rd party OpenStack, it may be unacceptable 
> to let every user create his own customer action. What do you think?

Yes, correct. It requires reinstall. If your goal is to give users possibility 
to create custom actions "on the fly” then it’s now impossible in Mistral for 
fundamental reasons. We can’t let users upload arbitrary Python code via API 
for security reasons. However, we have a couple of ideas that we’re going to 
explore in order to partially close this gap:
Keep action code on a client-side, sort of what StackStorm does. But IMO we 
could think about automating it in a more elegant and transparent way. For 
example, we could use decorators in python code that would associate a function 
or a class with a certain workflow task. Then a workflow could call this code 
back while its running using some mechanism (i.e. some special action). In this 
case, however, we’d have to have a process handling callback requests from 
Mistral on a client side. The alternative: using HTTP Long Poll mechanism so 
that a client could claim available tasks itself.
We have BP [1] that describes the idea of using so-called action providers. It 
assumes that we can register trustworthy action providers that could 
dynamically provide new actions to Mistral. I personally like this idea and to 
some extent it would solve this issue but it requires some additional setup 
which works for cases like StackStorm but doesn’t work if we want to use 
Mistral as is, as a hosted workflow service.

Anyway, whatever solution we accept it will be a trade-off and depend on a 
particular use case.

Ad-hoc actions may also work for you if, for example, we create enough base 
actions that they could be built upon. Say if most of your actions are HTTP 
based then you can just create your own library (e.g. a workbook) of ad-hoc 
actions that will be wrappers around std.http.

Also look at what StackStorm does, it may also be helpful.

Thanks

[1] https://blueprints.launchpad.net/mistral/+spec/action-providers 
__
OpenStack Development Mailing List (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][Metering]How does metering agent work to calc traffic?

[Zhi Chang]

Hi, all
In order to calc bandwidth, how does metering agent work? For example, how 
does iptables looks like if I have a floating ip? I find some instructions 
about metering agent in 
https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth. And there is 
iptables picture, but it is not clear. Could anyone give me some details info 
about iptables rules?


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

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[WANG, Ming Hao (Tony T)]

Renat,

Thanks for your info.
I like your 
option2(https://blueprints.launchpad.net/mistral/+spec/action-providers). ☺
Any schedule for this? Looks like it isn’t started yet.

Thanks,
Tony

From: Renat Akhmerov [mailto:rakhme...@mirantis.com]
Sent: Monday, October 19, 2015 2:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as 
Ansible) in Mistral


On 19 Oct 2015, at 07:53, WANG, Ming Hao (Tony T) 
> wrote:

The “custom action” needs to re-install Mistral.
If the Mistral service is part of 3rd party OpenStack, it may be unacceptable 
to let every user create his own customer action. What do you think?

Yes, correct. It requires reinstall. If your goal is to give users possibility 
to create custom actions "on the fly” then it’s now impossible in Mistral for 
fundamental reasons. We can’t let users upload arbitrary Python code via API 
for security reasons. However, we have a couple of ideas that we’re going to 
explore in order to partially close this gap:

  *   Keep action code on a client-side, sort of what StackStorm does. But IMO 
we could think about automating it in a more elegant and transparent way. For 
example, we could use decorators in python code that would associate a function 
or a class with a certain workflow task. Then a workflow could call this code 
back while its running using some mechanism (i.e. some special action). In this 
case, however, we’d have to have a process handling callback requests from 
Mistral on a client side. The alternative: using HTTP Long Poll mechanism so 
that a client could claim available tasks itself.
  *   We have BP [1] that describes the idea of using so-called action 
providers. It assumes that we can register trustworthy action providers that 
could dynamically provide new actions to Mistral. I personally like this idea 
and to some extent it would solve this issue but it requires some additional 
setup which works for cases like StackStorm but doesn’t work if we want to use 
Mistral as is, as a hosted workflow service.

Anyway, whatever solution we accept it will be a trade-off and depend on a 
particular use case.

Ad-hoc actions may also work for you if, for example, we create enough base 
actions that they could be built upon. Say if most of your actions are HTTP 
based then you can just create your own library (e.g. a workbook) of ad-hoc 
actions that will be wrappers around std.http.

Also look at what StackStorm does, it may also be helpful.

Thanks

[1] https://blueprints.launchpad.net/mistral/+spec/action-providers
__
OpenStack Development Mailing List (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] Fwd: [nova][mistral] Automatic evacuation as a long running task

[Matthew Booth]

Accidentally sent this privately.

-- Forwarded message --
From: Matthew Booth 
Date: Fri, Oct 9, 2015 at 6:14 PM
Subject: Re: [openstack-dev] [nova][mistral] Automatic evacuation as a long
running task
To: "Deja, Dawid" 


On Thu, Oct 8, 2015 at 12:51 PM, Deja, Dawid  wrote:

> Hi Matthew,
>
> Thanks for bringing some light on what problems has nova with evacuation
> of an instance. It is very important to have those limitations in mind when
> preparing final solution. Or to fix them, as you proposed.
>
> Nevertheless, I would say that evacuationD does more than what calling
> 'nova host-evacuate' do. Let's consider such scenario:
>
> 1. Call 'nova host evacuate HostX'
> 2. Caller dies during call - information that some VMs are still to be
> evacuated is lost.
>

No, it's not lost because the instances still have instance.host == source.
This means that you can (and must, in fact) simply run 'nova host-evacuate'
again if it didn't complete successfully the first time.

Note that an external agent (lets call it pacemaker) must solve exactly the
same problem in order to send a message to evacuated. It must assure itself
that it successfully 'sent a message' at least once, somewhere. Now replace
'sent a message' with 'ran nova host-evacuate'.


> Such thing would not happen with evacuationD, because it prepares one
> rabbitMQ message for each VM that needs to be evacuated. Moreover, it deals
> with situation, when process that lists VMs crashes. In such case, whole
> operation would be continued by another daemon.
>
> EvacD may also handle another problem that you mentioned: failure of
> target host of evacuation. In such scenario, 'evacuate host' message will
> be send for a new host and EvacD will try to evacuate all of it's vms -
> even those in rebuild state. Of course, evacuation of such instances fails,
> but they would eventually enter error state and evacuationD would start
> resurrection process. This can be speed up by setting instances state to
> 'error' (despite these which are in 'active' state) on the beginning of
> whole 'evacuate host' process.
>

Again, this situation is identical to simply running nova host-evacuate.
EvacD doesn't do any monitoring, and requires an external agent (we called
it pacemaker) to invoke it for the newly failed host. In this scenario,
whatever sends 'evacuate host' can instead run 'nova host-evacuate', and
the behaviour is identical.


>
> Finally, another action - called 'Look for VM' - could be added. It would
> check if given VM ended up in active state on new hosts; if no, VM could be
> rebuild. I hope this would give us as much certainty that VM is alive as
> possible.
>

This would add behaviour over nova host-evacuate. However, it would also be
considerably more complex to implement and what's there currently doesn't
add any infrastructure which enables it.

Remember that nova evacuate is not a heavy operation for the caller. It is
literally just a nova api call which returns after kicking off a task in
conductor. Running nova host-evacuate does:

1. List all instances
2. For instance 0, tell nova to initiate evac
3 ...

Running evacD does:
1. List all instances
2. For instance 0, send ourselves a message to initiate evac
... rabbit ...
3. For instance 0, tell nova to initiate evac

In other words, evacD just makes the call chain longer. It adds overhead
and additional potential points of failure. Ironically, this means the
resulting solution will be less robust.

Matt


> On Tue, 2015-10-06 at 16:34 +0100, Matthew Booth wrote:
> Hi, Roman,
>
> Evacuated has been on my radar for a while and this post has prodded me to
> take a look at the code. I think it's worth starting by explaining the
> problems in the current solution. Nova client is currently responsible for
> doing this evacuate. It does:
>
> 1. List all instances on the source host
> 2. Initiate evacuate for each instance
>
> Evacuating a single instance does:
>
> API:
> 1. Set instance task state to rebuilding
> 2. Create a migration record with source and dest if specified
>
> Conductor:
> 3. Call the scheduler to get a destination host if not specified
> 4. Get the migration object from the db
>
> Compute:
> 5. Rebuild the instance on dest
> 6. Update instance.host to dest
>
> Examining single instance evacuation, the first obvious thing to look at
> is what if 2 happen simultaneously. Because step 1 is atomic, it should not
> be possible to initiate 2 evacuations simultaneously of a single instance.
> However, note that this atomic action hasn't updated the instance host,
> meaning the source host remains the owner of this instance. If the
> evacuation process fails to complete, the source host will automatically
> delete it if it comes back up because it will find a migration record, but
> it will not be rebuilt anywhere else. Evacuating it again will fail,
> because its task state is already rebuilding.
>
> Also, 

Re: [openstack-dev] [neutron][stable] proactive backporting

[Ihar Hrachyshka]

> On 16 Oct 2015, at 17:36, Salvatore Orlando  wrote:
> 
> This sounds like a pretty decent idea to me. Considering Neutron's patch 
> merge rate this activity should hopefully not take a consistent chunk of your 
> Friday.

Actually, it does, if you consider other stable maintenance activities like 
reviewing existing stable backports in all stadium projects (side note: I 
believe it should not be the sole neutron-stable-maint members responsibility 
but subprojects should get their stable cores); tracking stable gate state; now 
walking thru bugs mentioned in commit messages. I would say, it takes ~2h each 
week to keep up.

But that’s not a big deal, just wanted to give clue.

> It might also make sense to ask contributors to resume the habit of tagging 
> bugs with 'backport-potential' even if not in the RC period.
> 

Yes. Is it even bound to RC period now? I didn’t think so.

Tracking the stable backport tags and moving them from -backport-potential to 
-in- tags is another thing I want us to do consistently (that would be 
another element in the process after we are settled with proactive backporting).

> I am glad to offer my help as well in evaluating "backport worthiness", and 
> the process you outlined looks very good to me.
> If there's any discussion needed for assessing whether a bug fix should be 
> backported or not, we could either use the etherpad or launchpad, with a 
> slight preference for launchpad.

Probably links to bugs for discussion in the etherpad and actual discussion in 
LP? Another alternative is having a separate tag for bugs with unclear 
backporting status.

Ihar


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

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

[Nikola Đipanov]

On 10/19/2015 11:13 AM, Tang Chen wrote:
> Hi, all,
> 
> If you don't mind, how about approve the BP, and I can start this work.
> 

This is IMHO the biggest drawback of the current spec process (as I've
written before).

There is no reason why you should doubt that this particular spec will
get approved, yet due to the combination of extremely limited review
bandwidth and very aggressive deadlines, there is a good chance your
spec will miss Mitaka release purely on process grounds.

This makes you even further dissuaded from actually putting in the
development effort.

N.

> Thanks. 
> 
> 
> On 10/15/2015 04:53 PM, Tang Chen wrote:
>> Hi all,
>>
>> The spec is now available here:
>> https://review.openstack.org/#/c/235169/
>>
>> Please help to review.
>>
>> Thanks.
>>
>> On 10/14/2015 10:05 AM, Tang Chen wrote:
>>> Hi, all,
>>>
>>> Please help to review this BP.
>>>
>>> https://blueprints.launchpad.net/nova/+spec/live-migration-state-machine
>>>
>>>
>>> Currently, the migration_status field in Migration object is
>>> indicating the
>>> status of migration process. But in the current code, it is represented
>>> by pure string, like 'migrating', 'finished', and so on.
>>>
>>> The strings could be confusing to different developers, e.g. there are 3
>>> statuses representing the migration process is over successfully:
>>> 'finished', 'completed' and 'done'.
>>> And 2 for migration in process: 'running' and 'migrating'.
>>>
>>> So I think we should use constants or enum for these statuses.
>>>
>>>
>>> Furthermore, Nikola has proposed to create a state machine for the
>>> statuses,
>>> which is part of another abandoned BP. And this is also the work I'd
>>> like to go
>>> on with. Please refer to:
>>> https://review.openstack.org/#/c/197668/
>>> 
>>> https://review.openstack.org/#/c/197669/
>>> 
>>>
>>>
>>> Another proposal is: introduce a new member named "state" into Migration.
>>> Use a state machine to handle this Migration.state, and leave
>>> migration_status
>>> field a descriptive human readable free-form.
>>>
>>>
>>> So how do you think ?
>>>
>>> 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

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

[Alex Xu]

Hi,

We have weekly Nova API meeting this week. The meeting is being held
Tuesday UTC1200.

In other timezones the meeting is at:

EST 08:00 (Tue)
Japan 21:00 (Tue)
China 20:00 (Tue)
United Kingdom 13:00 (Tue)

The proposed agenda and meeting details are here:

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

Please feel free to add items to the agenda.
__
OpenStack Development Mailing List (not for 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

[Tom Fifield]

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.



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-dev] [Fuel][Plugins][Ironic] Deploy Ironic with fuel ?

[loic.nicolle]

Hello,

I'm currently searching for information about Ironic Fuel plugin : 
https://github.com/openstack/fuel-plugin-ironic I don't find any documentation 
on it.

I've tried to install and deploy an Openstack environment with Fuel 7.0 and 
Ironic plugin but it failed. After adding ironic role to a node Fuel UI 
crashed, due to a missing network "baremetal" . When creating a network group

fuel network-group --create --node-group 1 --name \
"baremetal" --cidr 192.168.3.0/24
UI works again, but I got some errors in the deployment, during network 
configuration. So I think I have to configure a network template, did someone 
already do this for this plugin ?

Regards,

Loic

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank 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 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 default, for the same reason we
>> don't require our users to install pip libraries - there is less
>> security guarantees from pypi and rubygems than from distro packages,
>> plus corporate infrastructure may not allow pulling packages from these
>> types of sources. (I don't see this policy documented 

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[WANG, Ming Hao (Tony T)]

Dmitri,

>From StackStorm's document, it can run Mistral's workflow, and Mistral 
>workflow can call StackStorm custom actions.
Could you please help to explain how it is implemented?

examples.mistral-basic:
description: A basic workflow that runs an arbitrary linux command.
type: direct
input:
- cmd
output:
stdout: <% $.stdout %>
tasks:
task1:
action: core.local cmd=<% $.cmd %>  Here calls StackStorm 
custom action.
publish:
stdout: <% $.task1.stdout %>
stderr: <% $.task1.stderr %>

Thanks,
Tony


From: Dmitri Zimine [mailto:dzim...@stackstorm.com]
Sent: Sunday, October 18, 2015 1:27 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as 
Ansible) in Mistral

Tony,

You can also connect Mistral with Ansible via StackStorm and Ansible 
integration pack:
1) StackStorm http://docs.stackstorm.com
2) https://github.com/StackStorm/st2contrib/tree/master/packs/ansible

StackStorm is open-source Apache 2.0 "wrapper" around Mistral workflow service 
that integrates 3rd party tools.

Disclosure: I work for StackStorm, I think it's appropriate to pitch here an 
open source project that addresses the problem.

DZ.


On Oct 15, 2015, at 11:35 PM, WANG, Ming Hao (Tony T) 
> wrote:


Dear Mistral developers and testers,

We have developed some Ansible playbooks for operation automation, and we are 
investigating if we can change the automation engine from Ansible to Mistral 
since Mistral has powerful workflow control.
Could you please help to provide how to let Mistral call Ansible playbook or 
Ansible module?
My understanding is to use ssh std_action to let Mistral access Ansible server 
to call Ansible playbook/modules since Mistral ad-hoc action must base on an 
existing system action.

Another question is:
If we install Mistral and Ansible on a same server, is it possible to simplify 
it?

Thanks in advance,
Tony

__
OpenStack Development Mailing List (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] [Glance] Mitaka spec freeze proposal

[Flavio Percoco]

On 16/10/15 16:34 +0900, Flavio Percoco wrote:

Hi Glancers,

Among the things we'd like to give a try to during Mitaka, we also
have having a spec freeze. This was discussed in the latest drivers
meeting[0] and you can find some extra details below.

The freeze will happen after M-1 is cut and before M-2 is out. To be
more precise and allow for scheduling work, we've picked exact dates
for this freeze. The freeze will be on the week of November 28th and
December 1st. This, according to the OpenStack release schedule[1],
will happen 14 weeks before the Mitaka release.


ooops, I meant December 28th, Jannuary 1st.



These freeze will allow for exceptions to be proposed. However, such
exceptions must be compliant with the cycle priorities and achievable
in the remaining time for development (using the Feature Freeze as the
final date for it). Other specs will have to be targetted to the N
release.

Please, provide feedback and let us know what you think
Flavio

[0] 
http://eavesdrop.openstack.org/meetings/glance_drivers/2015/glance_drivers.2015-10-13-14.01.log.html
[1] https://wiki.openstack.org/wiki/Mitaka_Release_Schedule

--
@flaper87
Flavio Percoco


This has now been scheduled.

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] [cinder] NFS mount as cinder user instead of root

[Tom Barron]

On 10/14/15 6:31 AM, Francesc Pinyol Margalef wrote:
> Hi,
> Yes, that worked! Thanks! :)
> 
> But the process is very slow (about half an hour to create a volume).
> I think the problem is the execution of "du -sb --apparent-size
> --exclude *snapshot*
> /var/lib/cinder/mnt/9ae799cf301b19940950ae49dd800c51", as shown in the logs:
> 
> 2015-10-13 19:33:14.127 1311 INFO
> cinder.volume.flows.manager.create_volume
> [req-f52e5048-3155-4d49-92c0-4152b8243fd6
> 26e01a732d9e44d4a98305c6aa11860f 36593fc96ab64bc7959eb9e0ff2f2247 - - -]
> Volume 5230104d-68a3-4dc0-95ec-43f5d8fbc5d3: b
> eing created as raw with specification: {'status': u'creating',
> 'volume_size': 1, 'volume_name':
> u'volume-5230104d-68a3-4dc0-95ec-43f5d8fbc5d3'}
> 2015-10-13 19:33:14.140 1311 INFO cinder.brick.remotefs.remotefs
> [req-f52e5048-3155-4d49-92c0-4152b8243fd6
> 26e01a732d9e44d4a98305c6aa11860f 36593fc96ab64bc7959eb9e0ff2f2247 - - -]
> Already mounted: /var/lib/cinder/mnt/9ae799cf301b19940950
> ae49dd800c51
> 2015-10-13 19:40:27.556 1311 WARNING cinder.openstack.common.loopingcall
> [req-0a4a8e09-f10b-4dc6-96bf-f7e333635f99 - - - - -] task u' method Service.periodic_tasks of  0x2c5c650>>' run outlasted int
> erval by 499.80 sec
> 2015-10-13 19:40:27.564 1311 INFO cinder.volume.manager
> [req-5b14e3f3-76d9-484e-819b-46da8f0e29a6 - - - - -] Updating volume status
> 2015-10-13 19:40:27.577 1311 INFO cinder.brick.remotefs.remotefs
> [req-5b14e3f3-76d9-484e-819b-46da8f0e29a6 - - - - -] Already mounted:
> /var/lib/cinder/mnt/9ae799cf301b19940950ae49dd800c51
> 2015-10-13 19:51:37.371 1311 WARNING cinder.openstack.common.loopingcall
> [req-5b14e3f3-76d9-484e-819b-46da8f0e29a6 - - - - -] task u' method Service.periodic_tasks of  0x2c5c650>>' run outlasted int
> erval by 609.81 sec
> 2015-10-13 19:51:37.378 1311 INFO cinder.volume.manager
> [req-941c5a78-a85d-4fa8-9df9-033b4cc6e6f5 - - - - -] Updating volume status
> 2015-10-13 19:51:37.391 1311 INFO cinder.brick.remotefs.remotefs
> [req-941c5a78-a85d-4fa8-9df9-033b4cc6e6f5 - - - - -] Already mounted:
> /var/lib/cinder/mnt/9ae799cf301b19940950ae49dd800c51
> 2015-10-13 19:58:18.585 1311 ERROR cinder.openstack.common.periodic_task
> [req-941c5a78-a85d-4fa8-9df9-033b4cc6e6f5 - - - - -] Error during
> VolumeManager._report_driver_status: Unexpected error while running command.
> Command: None
> Exit code: -
> Stdout: u"Unexpected error while running command.\nCommand: du -sb
> --apparent-size --exclude *snapshot*
> /var/lib/cinder/mnt/9ae799cf301b19940950ae49dd800c51\nExit code:
> -15\nStdout: u''\nStderr: u''"
> Stderr: None
> 2015-10-13 19:58:18.585 1311 TRACE cinder.openstack.common.periodic_task
> Traceback (most recent call last):
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task   File
> "/usr/lib/python2.7/site-packages/cinder/openstack/common/periodic_task.py",
> line 224, in run_periodic_tasks
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task task(self, context)
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task   File
> "/usr/lib/python2.7/site-packages/cinder/volume/manager.py", line 1499,
> in _report_driver_status
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task volume_stats =
> self.driver.get_volume_stats(refresh=True)
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task   File
> "/usr/lib/python2.7/site-packages/osprofiler/profiler.py", line 105, in
> wrapper
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task return f(*args, **kwargs)
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task   File
> "/usr/lib/python2.7/site-packages/cinder/volume/drivers/remotefs.py",
> line 439, in get_volume_stats
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task self._update_volume_stats()
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task   File
> "/usr/lib/python2.7/site-packages/cinder/volume/drivers/remotefs.py",
> line 458, in _update_volume_stats
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task capacity, free, used =
> self._get_capacity_info(share)
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task   File
> "/usr/lib/python2.7/site-packages/cinder/volume/drivers/nfs.py", line
> 281, in _get_capacity_info
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task run_as_root=run_as_root)
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task   File
> "/usr/lib/python2.7/site-packages/cinder/utils.py", line 143, in execute
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task return
> processutils.execute(*cmd, **kwargs)
> 2015-10-13 19:58:18.585 1311 TRACE
> cinder.openstack.common.periodic_task   File
> "/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py",
> line 233, in execute
> 2015-10-13 

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

[Dmitry Mescheryakov]

Hello folks,

I second Patrick's idea. In our case we would like to install standalone
RabbitMQ cluster with Fuel reference architecture to perform destructive
tests on it. Requirement to install controller is an excessive burden in
that case.

Thanks,

Dmitry

2015-10-19 13:44 GMT+03:00 Patrick Petit :

> Hi There,
>
> There are situations where we’d like to deploy only Fuel plugins in an
> environment.
> That’s typically the case with Elasticsearch and InfluxDB plugins of LMA
> tools.
> Currently it’s not possible because you need to at least have one
> controller.
> What exactly is making that limitation? How hard would it be to have it
> removed?
>
> Thanks
> Patrick
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Next Nova meeting on November 4th 2015

[John Garbutt]

Hi,

Due to the summit, we decided the next meeting will be:
November 4th 2015 2100 UTC, #openstack-meeting
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20151104T21

For more details, as usual, please see:
https://wiki.openstack.org/wiki/Meetings/Nova

As normal, any questions, please do ask.

Thanks,
johnthetubaguy

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

[Tang Chen]

Hi Nikola,

On 10/19/2015 06:52 PM, Nikola Đipanov wrote:

On 10/19/2015 11:13 AM, Tang Chen wrote:

Hi, all,

If you don't mind, how about approve the BP, and I can start this work.


This is IMHO the biggest drawback of the current spec process (as I've
written before).

There is no reason why you should doubt that this particular spec will
get approved, yet due to the combination of extremely limited review
bandwidth and very aggressive deadlines, there is a good chance your
spec will miss Mitaka release purely on process grounds.

This makes you even further dissuaded from actually putting in the
development effort.


Sorry, I didn't realize the limited review bandwidth. Actually I don't
have a deadline of this.

And OK, let's keep its status so that more people could review it,
and minimize the waste of development effort.

Thanks.



N.


Thanks.


On 10/15/2015 04:53 PM, Tang Chen wrote:

Hi all,

The spec is now available here:
https://review.openstack.org/#/c/235169/

Please help to review.

Thanks.

On 10/14/2015 10:05 AM, Tang Chen wrote:

Hi, all,

Please help to review this BP.

https://blueprints.launchpad.net/nova/+spec/live-migration-state-machine


Currently, the migration_status field in Migration object is
indicating the
status of migration process. But in the current code, it is represented
by pure string, like 'migrating', 'finished', and so on.

The strings could be confusing to different developers, e.g. there are 3
statuses representing the migration process is over successfully:
'finished', 'completed' and 'done'.
And 2 for migration in process: 'running' and 'migrating'.

So I think we should use constants or enum for these statuses.


Furthermore, Nikola has proposed to create a state machine for the
statuses,
which is part of another abandoned BP. And this is also the work I'd
like to go
on with. Please refer to:
https://review.openstack.org/#/c/197668/

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



Another proposal is: introduce a new member named "state" into Migration.
Use a state machine to handle this Migration.state, and leave
migration_status
field a descriptive human readable free-form.


So how do you think ?

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
.




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

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

[WANG, Ming Hao (Tony T)]

Dmitri,

I think I got it.

"st2/st2common/st2common/util/workflow/mistral.py"
StackStorm uses function "_transform_action" here to transform action from 
StackStorm action style to "st2.action" style, and then call Mistral to execute 
workflow, since "st2.action" is Mistral's custom action.
Please help to double confirm.

Thanks,
Tony

From: WANG, Ming Hao (Tony T)
Sent: Monday, October 19, 2015 6:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [mistral] How to call 3rd-party tools(such as 
Ansible) in Mistral

Dmitri,

>From StackStorm's document, it can run Mistral's workflow, and Mistral 
>workflow can call StackStorm custom actions.
Could you please help to explain how it is implemented?

examples.mistral-basic:
description: A basic workflow that runs an arbitrary linux command.
type: direct
input:
- cmd
output:
stdout: <% $.stdout %>
tasks:
task1:
action: core.local cmd=<% $.cmd %>  Here calls StackStorm 
custom action.
publish:
stdout: <% $.task1.stdout %>
stderr: <% $.task1.stderr %>

Thanks,
Tony


From: Dmitri Zimine [mailto:dzim...@stackstorm.com]
Sent: Sunday, October 18, 2015 1:27 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as 
Ansible) in Mistral

Tony,

You can also connect Mistral with Ansible via StackStorm and Ansible 
integration pack:
1) StackStorm http://docs.stackstorm.com
2) https://github.com/StackStorm/st2contrib/tree/master/packs/ansible

StackStorm is open-source Apache 2.0 "wrapper" around Mistral workflow service 
that integrates 3rd party tools.

Disclosure: I work for StackStorm, I think it's appropriate to pitch here an 
open source project that addresses the problem.

DZ.


On Oct 15, 2015, at 11:35 PM, WANG, Ming Hao (Tony T) 
> wrote:

Dear Mistral developers and testers,

We have developed some Ansible playbooks for operation automation, and we are 
investigating if we can change the automation engine from Ansible to Mistral 
since Mistral has powerful workflow control.
Could you please help to provide how to let Mistral call Ansible playbook or 
Ansible module?
My understanding is to use ssh std_action to let Mistral access Ansible server 
to call Ansible playbook/modules since Mistral ad-hoc action must base on an 
existing system action.

Another question is:
If we install Mistral and Ansible on a same server, is it possible to simplify 
it?

Thanks in advance,
Tony

__
OpenStack Development Mailing List (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] Cross-project meeting, Tue Oct 20th, 21:00 UTC

[Emilien Macchi]

Dear PTLs, cross-project liaisons, and interested team members,

We'll have a cross-project meeting tomorrow at 21:00 UTC, with the
following agenda:

https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda

Review past action items
Team announcements (horizontal, vertical, diagonal)
Open discussion

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

See you there,
-- 
Emilien Macchi



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

Re: [openstack-dev] [all] jobs that make break when we remove Devstack extras.d in 10 weeks

[Victor Ryzhenkin]

 From now until the removal of devstack extras.d support I'm going to 
 send a weekly email of jobs that may break. A warning was added that we 
 can track in logstash. 

Hey!

Thanks for notification!
Murano team is on track to drop support usage of extras.d. [0]

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

-- 
Victor Ryzhenkin
Junior QA Engeneer
freerunner on #freenode

Включено 12 октября 2015 г. в 14:29:48, Sean Dague (s...@dague.net) написал:

On 10/12/2015 07:12 AM, Dmitry Tantsur wrote:  
> On 10/09/2015 05:41 PM, Dmitry Tantsur wrote:  
>> On 10/09/2015 12:58 PM, Dmitry Tantsur wrote:  
>>> On 10/09/2015 12:35 PM, Sean Dague wrote:  
 From now until the removal of devstack extras.d support I'm going to  
 send a weekly email of jobs that may break. A warning was added that we  
 can track in logstash.  
  
 Here are the top 25 jobs (by volume) that are currently tripping the  
 warning:  
  
 gate-murano-devstack-dsvm  
 gate-cue-integration-dsvm-rabbitmq  
 gate-murano-congress-devstack-dsvm  
 gate-solum-devstack-dsvm-centos7  
 gate-rally-dsvm-murano-task  
 gate-congress-dsvm-api  
 gate-tempest-dsvm-ironic-agent_ssh  
 gate-solum-devstack-dsvm  
 gate-tempest-dsvm-ironic-pxe_ipa-nv  
 gate-ironic-inspector-dsvm-nv  
 gate-tempest-dsvm-ironic-pxe_ssh  
 gate-tempest-dsvm-ironic-parallel-nv  
 gate-tempest-dsvm-ironic-pxe_ipa  
 gate-designate-dsvm-powerdns  
 gate-python-barbicanclient-devstack-dsvm  
 gate-tempest-dsvm-ironic-pxe_ssh-postgres  
 gate-rally-dsvm-designate-designate  
 gate-tempest-dsvm-ironic-pxe_ssh-dib  
 gate-tempest-dsvm-ironic-agent_ssh-src  
 gate-tempest-dsvm-ironic-pxe_ipa-src  
 gate-muranoclient-dsvm-functional  
 gate-designate-dsvm-bind9  
 gate-tempest-dsvm-python-ironicclient-src  
 gate-python-ironic-inspector-client-dsvm  
 gate-tempest-dsvm-ironic-lib-src-nv  
  
 (You can view this query with http://goo.gl/6p8lvn)  
  
 The ironic jobs are surprising, as something is crudding up extras.d  
 with a file named 23, which isn't currently run. Eventual removal of  
 that directory is going to potentially make those jobs fail, so someone  
 more familiar with it should look into it.  
>>>  
>>> Thanks for noticing, looking now.  
>>  
>> As I'm leaving for the weekend, I'll post my findings here.  
>>  
>> I was not able to spot what writes these files (in my case it was named  
>> 33). I also was not able to reproduce it on my regular devstack  
>> environment.  
>>  
>> I've posted a temporary patch https://review.openstack.org/#/c/233017/  
>> so that we're able to track where and when these files appear. Right now  
>> I only understood that they really appear during the devstack run, not  
>> earlier.  
>  
> So, no file seems to be created, so it looks like a problem in devstack:  
> https://review.openstack.org/#/c/233584/  

Oh, good catch. We can fix it with making i a local instead though, I'll  
spin a patch for that.  

-Sean  

--  
Sean Dague  
http://dague.net  

__  
OpenStack Development Mailing List (not for usage questions)  
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe  
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  
__
OpenStack Development Mailing List (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] [cloudkitty] IRC meetings canceled for two weeks

[Stéphane Albert]

Hi,

The summit is coming and most people are already in Japan. This makes
the organisation of meetings pretty difficult.
We'll cancel this week's meeting and next weeks too as most of the
contributors will be in Tokyo talking CloudKitty's future.

We'll resume normal schedule after the summit.

Cheers

__
OpenStack Development Mailing List (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] [puppet] weekly meeting #56

[Emilien Macchi]

Hello!

Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151020

Note: some people have some actions, please have a look at the etherpad!

Feel free to add any items you'd like to discuss.
If our schedule allows it, we'll make bug triage during the meeting.

Thanks,
-- 
Emilien Macchi



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

Re: [openstack-dev] [oslo] Require documenting changes with versionadded and versionchanged

[Ihar Hrachyshka]

> On 16 Oct 2015, at 13:02, Victor Stinner  wrote:
> 
> Le 15/10/2015 17:54, Joshua Harlow a écrit :
>> I had this problem with deprecation versioning (the debtcollector
>> library functions take a version="XYZ", removal_version="ABC" params,
>> see
>> http://docs.openstack.org/developer/debtcollector/examples.html#further-customizing-the-emitted-messages)
>> and it is pretty hard to get those two numbers right, especially with
>> weekly releases and not knowing when a review will merge... I'm not
>> saying we shouldn't try to do this, but we just have to figure out how
>> to do it in a smart way.
> 
> I hope that we will not release *too* frequently. Oslo libraries are supposed 
> to be somehow "stable" :-) Past history showed that any minor change has 
> major impact on the OpenStack CI ;-)

Once we have all major gate jobs using constraints file from 
openstack/requirements, we should not affect CI and hence development pace. I 
think neutron gate is quite close to that goal (we already have -constraints 
jobs for pep8/doc/py* jobs), and I believe other projects should follow the 
lead.

Once we are there, no oslo release should break the world. That of course does 
not mean we can release breaking changes, but it should make mistakes less 
painful.

Ihar


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

Re: [openstack-dev] [neutron][stable] proactive backporting

[Miguel Angel Ajo]

I thought that may be, some of the work Ihar is proposing, could be 
automated.


Like, for example, checking if bug fixes are backportable as-is to the 
previous stable

branches, and if they pass testing.

If that's the case, the bot could automatically automatically add the 
bug to the list, or
flag it with some sort of specific flag, so, we humans could verify it 
does make sense
to backport such bug, and if it actually meets the "backportable" 
guidelines.




Kuvaja, Erno wrote:

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Friday, October 16, 2015 1:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][stable] proactive backporting

Hi all,

I’d like to introduce a new initiative around stable branches for neutron
official projects (neutron, neutron-*aas, python-neutronclient) that is
intended to straighten our backporting process and make us more proactive
in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a
known bug hits a user that consumes stable branches, but backport fixes in
advance quickly after they hit master.

The idea is simple: every Fri I walk thru the new commits merged into master
since last check; produce lists of bugs that are mentioned in Related-
Bug/Closes-Bug; paste them into:

https://etherpad.openstack.org/p/stable-bug-candidates-from-master

Then I click thru the bug report links to determine whether it’s worth a
backport and briefly classify them. If I have cycles, I also request backports
where it’s easy (== a mere 'Cherry-Pick to' button click).

After that, those interested in maintaining neutron stable branches can take
those bugs one by one and handle them, which means: checking where it
really applies for backport; creating backport reviews (solving conflicts,
making tests pass). After it’s up for review for all branches affected and
applicable, the bug is removed from the list.

I started on that path two weeks ago, doing initial swipe thru all commits
starting from stable/liberty spin off. If enough participants join the process,
we may think of going back into git history to backport interesting fixes from
stable/liberty into stable/kilo.

Don’t hesitate to ask about details of the process, and happy backporting,

Ihar


Hi,

This looks like neat way to do it. In Glance we're doing constantly proactive backporting 
and I have been nominating bugs for series' and approving backports for a while now. We 
prefer not to have user coming to us and telling that they hit to bug in 
"stable" we had known already for ages, just didn't bother to backport the fix. 
 It has worked out really well and people are learning to propose these without me 
needing to read every single commit message.

Good luck, has worked great for us!

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

[Tang Chen]

Hi, all,

If you don't mind, how about approve the BP, and I can start this work.

Thanks.


On 10/15/2015 04:53 PM, Tang Chen wrote:

Hi all,

The spec is now available here:
https://review.openstack.org/#/c/235169/

Please help to review.

Thanks.

On 10/14/2015 10:05 AM, Tang Chen wrote:

Hi, all,

Please help to review this BP.

https://blueprints.launchpad.net/nova/+spec/live-migration-state-machine


Currently, the migration_status field in Migration object is 
indicating the

status of migration process. But in the current code, it is represented
by pure string, like 'migrating', 'finished', and so on.

The strings could be confusing to different developers, e.g. there are 3
statuses representing the migration process is over successfully:
'finished', 'completed' and 'done'.
And 2 for migration in process: 'running' and 'migrating'.

So I think we should use constants or enum for these statuses.


Furthermore, Nikola has proposed to create a state machine for the 
statuses,
which is part of another abandoned BP. And this is also the work I'd 
like to go

on with. Please refer to:
https://review.openstack.org/#/c/197668/ 

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




Another proposal is: introduce a new member named "state" into Migration.
Use a state machine to handle this Migration.state, and leave 
migration_status

field a descriptive human readable free-form.


So how do you think ?

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] [Neutron] [Tempest] where fwaas tempest tests should be?

[Takashi Yamamoto]

hi,

On Mon, Oct 19, 2015 at 5:33 PM, Ihar Hrachyshka  wrote:
>> On 16 Oct 2015, at 10:50, Takashi Yamamoto  wrote:
>>
>> if i move fwaas tests from neutron to neutron-fwaas, [1]
>> is there easy way to run them together with the rest of neutron api tests
>> for gate-neutron-dsvm-api job?
>
> Before we jump in to reflect current gating status-quo, do we have a definite 
> answer why we want to keep the gate coupling in place? Can’t we leave the 
> fwaas api job for fwaas repo only? Do we think core is unstable enough to 
> justify additional coupling? Is core bad at handling backwards compatibility 
> when it comes to (re)moving code that is unneeded for the core repo?
>
> That may actually be a dumb question, so don’t hesitate to point out obvious 
> reasons to keep co-gating.

it sounds like a good question.
i tend to think fwaas jobs for fwaas repo only is good enough.

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

__
OpenStack Development Mailing List (not for 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] [Tempest] where fwaas tempest tests should be?

[Takashi Yamamoto]

hi,

On Mon, Oct 19, 2015 at 2:52 PM, Takashi Yamamoto  wrote:
> hi,
>
> On Thu, Oct 15, 2015 at 11:22 PM, Matthew Treinish  
> wrote:
>> On Thu, Oct 15, 2015 at 09:02:22AM -0400, Assaf Muller wrote:
>>> On Thu, Oct 15, 2015 at 7:25 AM, Takashi Yamamoto 
>>> wrote:
>>>
>>> > hi,
>>> >
>>> > i'm looking in fwaas tempest tests and have a question about code 
>>> > location.
>>> >
>>> > currently,
>>> >
>>> > - fwaas api tests and its rest client are in neutron repo
>>> > - there are no fwaas scenario tests
>>> >
>>> > eventually,
>>> >
>>> > - fwaas api tests should be moved into neutron-fwaas repo
>>> > - fwaaa scenario tests should be in neutron-fwaas repo too.
>>> >
>>>
>>> I believe scenario tests that invoke APIs outside of Neutron should
>>> stay (Or be introduced to) Tempest.
>>
>> So testing the neutron advanced services was actually one of the first things
>> we decided was out of scope for tempest. (like well over a year ago) It took
>> some time to get equivalent testing setup elsewhere, but tests and support 
>> for
>> the advanced services were removed from tempest on purpose. I'd suggest that
>> you look at the tempest plugin interface:
>>
>> http://docs.openstack.org/developer/tempest/plugin.html
>>
>> if you'd like to make the fwaas tests (or any other adv. service tests)
>> integrate more cleanly with the rest of tempest.
>
> is there a clean way for a plugin to extend NetworkClientJSON for fwaas?

i created separate clients for each resources
as it seems the way tempest is going to take.
https://review.openstack.org/#/c/236890/

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

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

[openstack-dev] [Fuel][Plugins] Plugin deployment questions

[Patrick Petit]

Hi There,

There are situations where we’d like to deploy only Fuel plugins in an 
environment.
That’s typically the case with Elasticsearch and InfluxDB plugins of LMA tools.
Currently it’s not possible because you need to at least have one controller.
What exactly is making that limitation? How hard would it be to have it removed?

Thanks
Patrick__
OpenStack Development Mailing List (not for 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] Neutron rolling upgrade - are we there yet?

[Rossella Sblendido]

Hello Artur,

thanks for staring this thread. See inline please.

On 10/15/2015 05:23 PM, Ihar Hrachyshka wrote:

Hi Artur,

thanks a lot for caring about upgrades!

There are a lot of good points below. As you noted, surprisingly, we seem to 
have rolling upgrades working for RPC layer. Before we go into complicating 
database workflow by doing oslo.versionedobjects transition heavy-lifting, I 
would like us to spend cycles on making sure rolling upgrades work not just 
surprisingly, but also covered with appropriate gating (I speak grenade).


+1 agreed that the first step is to have test coverage then we can go on 
improving the process :)




I also feel that upgrades are in lots of ways not only a technical issue, but a 
cultural one too. You should have reviewers being aware of all the moving 
parts, and how a seemingly innocent change can break the flow. That’s why I 
plan to start on a devref page specifically about upgrades, where we could lay 
ground about which scenarios we should support, and those we should not (f.e. 
we have plenty of compatibility code in agents that to handle old controller 
scenario, which should not be supported); how all pieces interact and behave in 
transition, and what to look for during reviews. Hopefully, once such a page is 
up and read by folks, we will be able to have more meaningful conversation 
about our upgrade strategy.


On 14 Oct 2015, at 20:10, Korzeniewski, Artur  
wrote:

Hi all,

I would like to gather all upgrade activities in Neutron in one place, in order 
to summarizes the current status and future activities on rolling upgrades in 
Mitaka.



If you think it’s worth it, we can start up a new etherpad page to gather 
upgrade ideas and things to do.




1.  RPC versioning

a.  It is already implemented in Neutron.

b.  TODO: To have the rolling upgrade we have to implement the RPC version 
pinning in conf.

 i. I’m not a big fan 
of this solution, but we can work out better idea if needed.


As Dan pointed out, and as I think Miguel was thinking about, we can have pin 
defined by agents in the cluster. Actually, we can have per agent pin.


I am not a big fan either mostly because the pinning is a manual task. 
Anyway looking at the patch Dan linked 
https://review.openstack.org/#/c/233289/ ...if we remove the manual step 
I can become a fan of this approach :)






c.  Possible unit/functional tests to catch RPC version incompatibilities 
between RPC revisions.

d.  TODO: Multi-node Grenade job to have rolling upgrades covered in CI.


That is not for unit or functional test level.

As you mentioned, we already have grenade project that is designed to test 
upgrades. To validate RPC compatibility on rolling upgrade we would need so 
called ‘partial’ job (when different components are running with different 
versions; in case of neutron it would mean a new controller and old agents). 
The job is present in nova gate and validates RPC compatibility.

As far as I know, Russell Bryant was looking into introducing the job for 
neutron, but was blocked by ongoing grenade refactoring to support partial 
upgrades ‘the right way’ (using multinode setups). I think that we should check 
with grenade folks on that matter, I have heard start of Mitaka was ETA for 
this work to complete.



2.  Message content versioning – versioned objects

a.  TODO: implement Oslo Versionobject in Mitaka cycle. The interesting 
entities to be implemented: network, subnet, port, security groups…


Though we haven’t touched base neutron resources in Liberty, we introduced 
oslo.versionedobjects based NeutronObject class during Liberty as part of QoS 
effort. I plan to expand on that work during Mitaka.

The existing code for QoS resources can be found at:

https://github.com/openstack/neutron/tree/master/neutron/objects



b.  Will OVO have impact on vendor plugins?


It surely can have significant impact, but hopefully dict compat layer should 
make transition more smooth:

https://github.com/openstack/neutron/blob/master/neutron/objects/base.py#L50



c.  Be strict on changes in version objects in code review, any change in 
object structure should increment the minor (backward-compatible) or major 
(breaking change) RPC version.


That’s assuming we have a clear mapping of objects onto current RPC interfaces, 
which is not obvious. Another problem we would need to solve is core resource 
extensions (currently available in ml2 only), like qos or port_security, that 
modify resources based on controller configuration.



d.  Indirection API – message from newer format should be translated to 
older version by neutron server.


For QoS, we used a new object agnostic subscriber mechanism to propagate 
changes applied to QoS objects into agents: 
http://docs.openstack.org/developer/neutron/devref/rpc_callbacks.html

It is already (expected) to downgrade 

Re: [openstack-dev] [oslo] Require documenting changes with versionadded and versionchanged

[Davanum Srinivas]

Victor,

I'd like to continue the fast paced oslo releases. Last fire drill showed,
a few projects that depended on internals of how things we implemented in
oslo libraries. Examples were oslo.policy switching to requests from
urllib3 and the oslo.utils how it deals with exceptions for example. These
are better caught early. We still have to get projects to honor the
contracts say in oslo.messaging (stop() needs to be called before wait())
etc as well. in spite of the many LOG messages over the last few months,
projects have not done so as well. IMHO, oslo already has a very early
freeze compared to other projects. So we should take the hit early in terms
of releasing and finding problems IMHO. yes, +1000 we have to be more
careful.

Yes, "major gate jobs using constraints file from openstack/requirements"
will help as well. So fyi, the travis jobs i set up for running a handful
of py27/py34 jobs of different projects against master of all oslo.*
libraries is green today (https://travis-ci.org/dims/). So we will have a
bunch of libraries released today. https://review.openstack.org/#/c/236770/.
Heads up :)

So Net, Oslo should continue to push out releases every late monday / early
tuesday (US eastern time). and i'd request all the Oslo cores to check
things out the end of previous week. So we can run all sorts of tests in
the weekend to make sure we don't break stuff.

Thanks,
Dims

On Mon, Oct 19, 2015 at 4:49 AM, Ihar Hrachyshka 
wrote:

> > On 16 Oct 2015, at 13:02, Victor Stinner  wrote:
> >
> > Le 15/10/2015 17:54, Joshua Harlow a écrit :
> >> I had this problem with deprecation versioning (the debtcollector
> >> library functions take a version="XYZ", removal_version="ABC" params,
> >> see
> >>
> http://docs.openstack.org/developer/debtcollector/examples.html#further-customizing-the-emitted-messages
> )
> >> and it is pretty hard to get those two numbers right, especially with
> >> weekly releases and not knowing when a review will merge... I'm not
> >> saying we shouldn't try to do this, but we just have to figure out how
> >> to do it in a smart way.
> >
> > I hope that we will not release *too* frequently. Oslo libraries are
> supposed to be somehow "stable" :-) Past history showed that any minor
> change has major impact on the OpenStack CI ;-)
>
> Once we have all major gate jobs using constraints file from
> openstack/requirements, we should not affect CI and hence development pace.
> I think neutron gate is quite close to that goal (we already have
> -constraints jobs for pep8/doc/py* jobs), and I believe other projects
> should follow the lead.
>
> Once we are there, no oslo release should break the world. That of course
> does not mean we can release breaking changes, but it should make mistakes
> less painful.
>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [neutron][stable] proactive backporting

[Kuvaja, Erno]

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Friday, October 16, 2015 1:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [neutron][stable] proactive backporting
> 
> Hi all,
> 
> I’d like to introduce a new initiative around stable branches for neutron
> official projects (neutron, neutron-*aas, python-neutronclient) that is
> intended to straighten our backporting process and make us more proactive
> in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a
> known bug hits a user that consumes stable branches, but backport fixes in
> advance quickly after they hit master.
> 
> The idea is simple: every Fri I walk thru the new commits merged into master
> since last check; produce lists of bugs that are mentioned in Related-
> Bug/Closes-Bug; paste them into:
> 
> https://etherpad.openstack.org/p/stable-bug-candidates-from-master
> 
> Then I click thru the bug report links to determine whether it’s worth a
> backport and briefly classify them. If I have cycles, I also request backports
> where it’s easy (== a mere 'Cherry-Pick to' button click).
> 
> After that, those interested in maintaining neutron stable branches can take
> those bugs one by one and handle them, which means: checking where it
> really applies for backport; creating backport reviews (solving conflicts,
> making tests pass). After it’s up for review for all branches affected and
> applicable, the bug is removed from the list.
> 
> I started on that path two weeks ago, doing initial swipe thru all commits
> starting from stable/liberty spin off. If enough participants join the 
> process,
> we may think of going back into git history to backport interesting fixes from
> stable/liberty into stable/kilo.
> 
> Don’t hesitate to ask about details of the process, and happy backporting,
> 
> Ihar

Hi,

This looks like neat way to do it. In Glance we're doing constantly proactive 
backporting and I have been nominating bugs for series' and approving backports 
for a while now. We prefer not to have user coming to us and telling that they 
hit to bug in "stable" we had known already for ages, just didn't bother to 
backport the fix.  It has worked out really well and people are learning to 
propose these without me needing to read every single commit message. 

Good luck, has worked great for us!

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

[openstack-dev] [mistral] Cancelling team meeting today - 10/19/2015

[Renat Akhmerov]

Team, let’s cancel today’s meeting since we all have lots of pre-summit 
activities.

Just in case if you still want to add your topics to discuss at the summit, 
here’s the link to the etherpad again: 
https://etherpad.openstack.org/p/mistral-tokyo-summit-2015 
. I’ll prettyfy it 
before the summit a little bit and most likely split into several independent 
etherpads for convenience.

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] Blueprint to change (expand) traditional Ethernet interface naming schema in Fuel

[Albert Syriy]

Hello,

Continue work on the Ethernet interfaces naming schema I create the
blueprint and spec for review:
https://blueprints.launchpad.net/fuel/+spec/network-interfaces-naming-schema
https://review.openstack.org/#/c/236848/

Because proposed changes potentially affect different components (and
actually it's out of my expertise) I would like to ask core reviewers to
assess the risks and write comment in corresponding sections (marked as
TODO).

Looking forward to your reply,

Albert Syriy,

Software Engineer,
Mirantis

On Fri, Oct 9, 2015 at 10:30 PM, Sergey Vasilenko 
wrote:

> >I would like to pay your attention to the changing interface naming
>> >schema, which is proposed to be implemented in FuelA [1].A In brief,
>> >Ethernet network interfaces may not be named as ethX, and there is a
>> >reported bug about itA [2]
>> >There are a lot of reasons to switch to the new naming schema, not
>> only
>> >because it has been used in CentOS 7 (and probably will be used in
>> next
>> >Ubuntu LTS), but becauseA new naming schema gave more predictable
>> >interface namesA [3]. There is a reported bug related to the topicA
>> [4]
>>
>
> L23network module is a interface naming scheme agnostic.
> Only bridge and bond interface name protection found -- You can't call
> bond or bridge like 'enp2s0', because this name reserved for NICs.
>
>
>
>> You might be interested to look at the os-net-config tool - we faced this
>> exact same issue with TripleO, and solved it via os-net-config, which
>> provides abstractions for network configuration, including mapping device
>> aliases (e.g "nic1") to real NIC names (e.g "em1" or whatever).
>>
>> https://github.com/openstack/os-net-config
>>
>>
> It's interesting project. Proposed format for network configuration, so
> interesting, but...
> Project too young. And doesn't allow to configure some things, that
> L23network already support.
> Main problem of this project -- is a approach to change interface options
> options. They doesn't use prefetch/flush mechanics as in the puppet. They
> just executing commands for change, instead in most cases. Such approach
> doesn't allow re-configure existing cloud properly, if one under production
> load.
>
> I can support config format from os-net-config as additional network
> scheme format too, but, IMHO, this hierarchical format not so convenient as
> flat.
>
> NIC mapping, in Nailgun, already implemented in the template-networking.
> If wee need use it for another cases -- ask Alexey Kasatkin, please.
>
> /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 Development Mailing List (not for 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] [Tempest] where fwaas tempest tests should be?

[Ihar Hrachyshka]

> On 16 Oct 2015, at 10:50, Takashi Yamamoto  wrote:
> 
> if i move fwaas tests from neutron to neutron-fwaas, [1]
> is there easy way to run them together with the rest of neutron api tests
> for gate-neutron-dsvm-api job?

Before we jump in to reflect current gating status-quo, do we have a definite 
answer why we want to keep the gate coupling in place? Can’t we leave the fwaas 
api job for fwaas repo only? Do we think core is unstable enough to justify 
additional coupling? Is core bad at handling backwards compatibility when it 
comes to (re)moving code that is unneeded for the core repo?

That may actually be a dumb question, so don’t hesitate to point out obvious 
reasons to keep co-gating.

Ihar


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

Re: [openstack-dev] [neutron] Neutron rolling upgrade - are we there yet?

[Miguel Angel Ajo]

Rossella Sblendido wrote:

Hello Artur,

thanks for staring this thread. See inline please.

On 10/15/2015 05:23 PM, Ihar Hrachyshka wrote:

Hi Artur,

thanks a lot for caring about upgrades!

There are a lot of good points below. As you noted, surprisingly, we 
seem to have rolling upgrades working for RPC layer. Before we go 
into complicating database workflow by doing oslo.versionedobjects 
transition heavy-lifting, I would like us to spend cycles on making 
sure rolling upgrades work not just surprisingly, but also covered 
with appropriate gating (I speak grenade).


+1 agreed that the first step is to have test coverage then we can go 
on improving the process :)




I also feel that upgrades are in lots of ways not only a technical 
issue, but a cultural one too. You should have reviewers being aware 
of all the moving parts, and how a seemingly innocent change can 
break the flow. That’s why I plan to start on a devref page 
specifically about upgrades, where we could lay ground about which 
scenarios we should support, and those we should not (f.e. we have 
plenty of compatibility code in agents that to handle old controller 
scenario, which should not be supported); how all pieces interact and 
behave in transition, and what to look for during reviews. Hopefully, 
once such a page is up and read by folks, we will be able to have 
more meaningful conversation about our upgrade strategy.


On 14 Oct 2015, at 20:10, Korzeniewski, Artur 
 wrote:


Hi all,

I would like to gather all upgrade activities in Neutron in one 
place, in order to summarizes the current status and future 
activities on rolling upgrades in Mitaka.




If you think it’s worth it, we can start up a new etherpad page to 
gather upgrade ideas and things to do.





1.  RPC versioning

a.  It is already implemented in Neutron.

b.  TODO: To have the rolling upgrade we have to implement the 
RPC version pinning in conf.


 i. I’m not 
a big fan of this solution, but we can work out better idea if needed.


As Dan pointed out, and as I think Miguel was thinking about, we can 
have pin defined by agents in the cluster. Actually, we can have per 
agent pin.


I am not a big fan either mostly because the pinning is a manual task. 
Anyway looking at the patch Dan linked 
https://review.openstack.org/#/c/233289/ ...if we remove the manual 
step I can become a fan of this approach :)


Yes, the minimum implementation we could agree on initially was pining. 
Direct request of objects from agents
to neutron-server includes the requested version, so that's always OK, 
the complicated part is notification of object

changes via fanout.

In that case, I thinking of including the supported object versions on 
agent status reports, so neutron server can
decide on runtime which versions to send (in some cases it may need to 
send several versions in parallel), I'm in
long due to upload the strategy to the rpc callbacks devref. But it will 
be along those lines.






c.  Possible unit/functional tests to catch RPC version 
incompatibilities between RPC revisions.


d.  TODO: Multi-node Grenade job to have rolling upgrades 
covered in CI.


That is not for unit or functional test level.

As you mentioned, we already have grenade project that is designed to 
test upgrades. To validate RPC compatibility on rolling upgrade we 
would need so called ‘partial’ job (when different components are 
running with different versions; in case of neutron it would mean a 
new controller and old agents). The job is present in nova gate and 
validates RPC compatibility.


As far as I know, Russell Bryant was looking into introducing the job 
for neutron, but was blocked by ongoing grenade refactoring to 
support partial upgrades ‘the right way’ (using multinode setups). I 
think that we should check with grenade folks on that matter, I have 
heard start of Mitaka was ETA for this work to complete.




2.  Message content versioning – versioned objects

a.  TODO: implement Oslo Versionobject in Mitaka cycle. The 
interesting entities to be implemented: network, subnet, port, 
security groups…


Though we haven’t touched base neutron resources in Liberty, we 
introduced oslo.versionedobjects based NeutronObject class during 
Liberty as part of QoS effort. I plan to expand on that work during 
Mitaka.

++


The existing code for QoS resources can be found at:

https://github.com/openstack/neutron/tree/master/neutron/objects



b.  Will OVO have impact on vendor plugins?


It surely can have significant impact, but hopefully dict compat 
layer should make transition more smooth:


https://github.com/openstack/neutron/blob/master/neutron/objects/base.py#L50 



Correct.




c.  Be strict on changes in version objects in code review, any 
change in object structure should increment the minor 
(backward-compatible) or major (breaking change) RPC 

Re: [openstack-dev] [fuel] PTL & Component Leads elections

[Sergey Lukjanov]

Hi folks,

it's time to start voting for the component leads.

There was only one candidate for the Fuel Python Component Lead, so, no
need for voting. Congrats to Igor Kalnitsky!

For the Fuel Library Component Lead we have two candidates and you should
receive an email with title "Poll: Fuel Library Component Lead Elections
Fall 2015" soon to vote for them. Please, don't share / forward this email,
it contains your personal unique token for the voting.

The estimated date for the voting end is Oct 22.

Thanks.

On Tue, Oct 13, 2015 at 4:05 PM, Tomasz Napierala 
wrote:

> Congrats Dmitry! Well deserved.
>
>
> > On 09 Oct 2015, at 19:13, Mike Scherbakov 
> wrote:
> >
> > Congratulations to Dmitry!
> > Now you are officially titled with PTL.
> > It won't be easy, but we will support you!
> >
> > 118 contributors voted. Thanks everyone! Thank you Sergey for organizing
> elections for us.
> >
> > On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov 
> wrote:
> > Voting period ended and so we have an officially selected Fuel PTL - DB.
> Congrats!
> >
> > Poll results & details -
> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0
> >
> > Let's start proposing candidates for the component lead positions!
> >
> > On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov 
> wrote:
> > Hi folks,
> >
> > I've just setup the voting system and you should start receiving email
> with topic "Poll: Fuel PTL Elections Fall 2015".
> >
> > NOTE: Please, don't forward this email, it contains *personal* unique
> token for the voting.
> >
> > Thanks.
> >
> > On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin 
> wrote:
> > +1 to Igor. Do we have voting system set up?
> >
> > On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky 
> wrote:
> > > * September 29 - October 8: PTL elections
> >
> > So, it's in progress. Where I can vote? I didn't receive any emails.
> >
> > On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala
> >  wrote:
> > >> On 18 Sep 2015, at 04:39, Sergey Lukjanov 
> wrote:
> > >>
> > >>
> > >> Time line:
> > >>
> > >> PTL elections
> > >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
> position
> > >> * September 29 - October 8: PTL elections
> > >
> > > Just a reminder that we have a deadline for candidates today.
> > >
> > > Regards,
> > > --
> > > Tomasz 'Zen' Napierala
> > > Product Engineering - Poland
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> __
> > > OpenStack Development Mailing List (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
> >
> >
> >
> > --
> > 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)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Sincerely yours,
> > Sergey Lukjanov
> > Sahara Technical Lead
> > (OpenStack Data Processing)
> > Principal Software Engineer
> > Mirantis Inc.
> >
> >
> >
> > --
> > Sincerely yours,
> > Sergey Lukjanov
> > Sahara Technical Lead
> > (OpenStack Data Processing)
> > Principal Software Engineer
> > Mirantis Inc.
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > --
> > 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
>
> --
> Tomasz 'Zen' Napierala
> Product Engineering - Poland
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)

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

[Ruby Loo]

Hi Ramesh,

On 15 October 2015 at 11:53, Ramakrishnan G 
wrote:

>
>
> So what all are the problems ?
> 1) Ability to update the driver documentation not-related to Ironic easily
> without waiting.
> 2) To save some core reviewers time who might not be familiar with the
> hardware.
>
> To solve the actual problem of updating the documentation easily while
> keeping it in-tree, I checked with infra folks if a subset of a repository
> can be +2ed/+Aed by another group.  They confirmed it's not possible
> (unless there was a communication gap in that conversation, folks can
> correct me if I am wrong).
>
> The following are the options that I can think of to address this:
>
> 1) Easy approvals for patches solely related to driver documentation. Once
> the driver team feels the documentation is ready, it can be +Aed by a core
> team member skipping the normal process of review. Of course, fixing any
> comments that come by, but not waiting for the normal rule of 2x+2s.
>

To date, when there is a driver documentation patch that is submitted, does
the driver team review them? Are there past cases where this has occurred
and there wasn't any 'useful' feedback from other reviewers before it got
the +A?


>
> 2) A separate repository for driver documentation controller by driver
> developers (a bad idea ??)
>

> 3) Allow to push driver documentation to wiki for those who wish to.
>

My preference is for the driver documentation to be outside any ironic
repository that I feel responsible for reviewing. I.e., I want to reduce
the number of patches that need to be reviewed :) I would love if the
driver documentation was outside, reviewed by the driver folks (however
they want to review it) and their own tech writers or whatever.

I took a look at Jim's comments on that patch and I'll copy some of it here
(hope you don't mind Jim):

-

Totally opposed to documentation on the wiki. Docs should be reviewed
(anyone with an Launchpad account can edit the wiki without review).

Also, in-tree docs are so much prettier, and can be tied to a release if we
decide to do so. :)

If there's too much overhead with keeping docs in tree, let's solve *that*
problem rather than just removing the docs.

--

Ramesh -- assuming I'm the odd person out and most people want the
documentation in-tree, let's try to look at and address the overhead with
keeping docs in tree. Perhaps you could elaborate on the problems (the 2
points you mention in your email). Eg, do people feel like there are too
many nits or other unnecessary comments that cause too many revisions for
very-little-benefit, or that no one 'ever' looks at the patch, or that even
a 1-day delay in getting a patch merged is too long, or what?

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

[openstack-dev] [cross-project] Admin

[Adam Young]

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.


We have a few choices.

1.  Remove Admin from the scoping for projects. Admin is a special role 
reserved only for system admins.  Replace project scoped admins with 
'manager' or some other comparable role.  This is actually the easiest 
solution.


2.  Create a special project for administrative actions.  Cloud admin 
users are assigned to this project. Communicate that project Id to the 
remote systems.  This is what the policy.v3cloudsample.json file 
(http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json) 
recommends.


However, 2 is really not practical without some significant 
engineering.  For a new deployment, it would require the following steps.

1) Every single policy file would have to be "templatized"
2) Then deployment mechanism would have to create the admin project, get 
the id for it, and string replace it in the policy file.


We could make this happen in Devstack.  The same is true of Puppet, 
OSAD, and Fuel.  There would be a lag and the downstream mechanisms 
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic 
Policy approach.  If OpenStack managed policy deployment via an 
inte4rnal mechanism, then adding things like the admin_project_id 
becomes trivial.



While I think Dynamic Policy provides a lot of value, I concede that it 
is overkill for just substituting in a single value.  The real reason I 
am backing off Dynamic Policy for the moment is that we need to better 
understand what part of policy should be dynamic and what part should be 
static;  we are just getting that clean now.



There is an additional dimension to the admin_project_id issue that 
several developers want solved.  In larger deployments, different users 
should have administrative capabilities on different endpoints.  
Sometimes this is segregated by service (storage admins vs network 
admins) and sometimes by region.


Having a special project clearly communicates the intention of RBAC.  
But even clearer would be to have the role assignment explicitly on the 
catalog item itself.  Which of the following statements would you think 
is clearer?



1) Assign Joe the admin role on the project designated to administer 
endpoint 0816.

2) 1) Assign Joe the admin role on endpoint 0816.

I think you will agree that it is the latter.  Making this happen would 
not be too difficult on the Keystone side, and would require fairly 
simple changes on the policy enforcement of the remote projects.  We've 
already discussed "endpoint binding of tokens" where an endpoint needs 
to know its own ID.  Having a new "scope" in a token that is endpoint_id 
would be fairly easy to execute.



One project, though, it that all of the client tooling would need to 
change.  Horizon, openstackclient, and keystoneauth would need to handle 
"endpoint" as the scope.  This includes third party integrations, which 
we do not control.



All of these constraints drive toward a solution where we link the admin 
project to the existing endpoint ids.


Make the catalog a separate domain.
Make regions, services, and endpoints projects
Use the rules of Hierarchical Multitenancy to manage the role 
assignments for a project.


On the enforcing side, endpoints *must* know their own ID.  They would 
have checks that assert token.project_id = self.endpoint_id.


This is the "least magic" approach.  It reuses existing abstractions 
without radically altering them.  The chance of a collision between an 
existing project_id and and endpoint_id is vanishingly small\, and could 
be addressed by modifying one or the other accordingly. The biggest 
effort would be in updating  the policy files, but this seems to be 
within the capability of  cross project efforts.



We will be discussing this at the Cross Project session at the summit  
on Global Admin


https://mitakadesignsummit.sched.org/event/51c8f2ea29aa0b63f85e424b0acf9741

Please read this, process it, and be ready to help come to a proper 
conclusion of this bug.

Re: [openstack-dev] [all] jobs that make break when we remove Devstack extras.d in 10 weeks

[Sean Dague]

On 10/19/2015 08:48 AM, Victor Ryzhenkin wrote:
>>  From now until the removal of devstack extras.d support I'm going to 
>>  send a weekly email of jobs that may break. A warning was added
>> that we 
>>  can track in logstash. 
> 
> Hey!
> 
> Thanks for notification!
> Murano team is on track to drop support usage of extras.d. [0]
> 
> [0] https://review.openstack.org/#/c/235868/

Thanks for keeping up on this. +2 on that review from me.

-Sean

-- 
Sean Dague
http://dague.net

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

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

[Ruby Loo]

Hi Wan-yen,

On 19 October 2015 at 01:46, Wan-yen Hsu  wrote:

>
>
>  I fully agreed with Ramesh.  There is a need for driver owners to be able
> to quickly update their driver’s document.  Particularly, vendor's drivers
> have strong
>

What do you mean by 'quickly'? Quicker than it has been in the past I
assume, but what time frame do you think is reasonable?


> dependencies on their platform’s firmware.  For instance, a new release of
> firmware may have impact on vendor’s driver and may require a specific
> firmware settings or some workaround in driver configuration.  Therefore
> driver owners need to be able to update their driver documents to reflect
> support of firmware versions or hardware platforms, document firmware
> issues that have impacts to the drivers, …etc.   Also, as more and more
> features added to the
>

Driver owners ARE able to update their driver documents by submitting
patches.


> drivers and some features are related, sometimes it requires restructuring
> of the document to make it easier for readers to follow and understand.  I
> would very much
>

If restructuring is needed to make the documentation better, I would
welcome that very much.


> like to get tech writers to help my driver’s document but with current
> document review process and release schedule, it’s just very hard to do.
> As the result, document quality
>
suffers.  I really wish that we can give driver owner’s
>

I don't understand this. If you cannot get tech writers to help with your
driver documentation and your doc quality suffers, how does giving the
driver owner (who presumably wrote the driver doc that is suffering) more
control help? The doc quality will still suffer, won't it?


> more control of their documents and be able to update their driver
> documents when needed.
>
>
>

Perhaps you could define what 'more control' means and how you feel like
you've been restricted from doing this in the past. That would make it
easier for me to try to help come up with something that can address this
issue.

--ruby
__
OpenStack Development Mailing List (not for 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] Driver documentation in Ironic

[Monty Taylor]

On 10/19/2015 01:46 AM, Wan-yen Hsu wrote:

  I fully agreed with Ramesh.  There is a need for driver owners to be
able to quickly update their driver’s document.  Particularly, vendor's
drivers have strong dependencies on their platform’s firmware.  For
instance, a new release of firmware may have impact on vendor’s driver
and may require a specific firmware settings or some workaround in
driver configuration.  Therefore driver owners need to be able to update
their driver documents to reflect support of firmware versions or
hardware platforms, document firmware issues that have impacts to the
drivers, …etc.   Also, as more and more features added to the drivers
and some features are related, sometimes it requires restructuring of
the document to make it easier for readers to follow and understand.  I
would very much like to get tech writers to help my driver’s document
but with current document review process and release schedule, it’s just
very hard to do.  As the result, document quality suffers.  I really
wish that we can give driver owner’s more control of their documents and
be able to update their driver documents when needed.

  Among all 3 options listed below, I prefer 2 or 3. Please consider
these options.



I am neither Ironic core, nor a driver developer - however ...


The following are the options that I can think of to address  this:



1) Easy approvals for patches solely related to driver  documentation. Once



the driver team feels the documentation is ready, it can be  +Aed by a core



team member skipping the normal process of review. Of  course, fixing any



comments that come by, but not waiting for the normal rule  of 2x+2s.


I like this one the best. It's easy to enable and needs no extra 
bureaucracy. In fact, it's a streamlining, which I think is good.



2) A separate repository for driver documentation controller  by driver



developers (a bad idea ??)


If you were going to make a docs repo outside of Ironic, I'd expect it 
to be under docs, and you'd have the same concern.



3) Allow to push driver documentation to wiki for those who  wish to.


I'm very much not a fan of this. We have a giant system for collecting 
and publishing code and documentation. Before we punt on that and just 
use a wiki for _some_ of the documentation (now meaning that docs are in 
two places) - let's just fix the social issue around it being hard for 
vendors to update their driver docs.



Thoughts ???



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




__
OpenStack Development Mailing List (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] [Cinder] New extension API for detecting cinder-backup ?

[Dulko, Michal]

On Fri, 2015-10-16 at 17:36 +, Ramakrishna, Deepti wrote:
> Thanks Duncan. 
>  
> Should I publish a BP and spec for this? And follow it up with code
> changes to the server, client, horizon and documentation? 
>  
> Thanks,
> Deepti 
> 

I believe a BP and spec is required as this is a new API call added.
Also having a spec makes it easier to discuss whole idea with rest of
the team.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] ERROR : openstack Forbidden (HTTP 403)

[Adam Young]

On 10/18/2015 02:25 AM, Emilien Macchi wrote:
WARNING: keystoneclient.auth.identity.generic.base Discovering 
versions from the identity service failed when creating the password 
plugin. Attempting to determine version from URL.


What is the AUTH_URL?  This warning alone is not a problem, but it comes 
when there is a mismatch between the expected version of the Identity 
API and the AUTH_URL version.


What is set for OS_IDENTITY_API_VERSION?


__
OpenStack Development Mailing List (not for 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] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Kyle Mestery]

On Sun, Oct 18, 2015 at 1:54 PM, Murali R  wrote:

> Will there be an irc opened for these sessions to join remotely?
>
> We will have people in the room who will be on IRC, yes, just use
#openstack-neutron. Even better, you can comment on the etherpad live while
the session is going on, which is a good way to attend remotely as well.


>
>
> On Sun, Oct 18, 2015 at 9:19 AM, Armando M.  wrote:
>
>> Perhaps adding a section for 'collecting ideas' right at the bottom of
>> the etherpad will help directing input.
>>
>> We should strive for keeping the session focussed, sessions are only 40
>> mins, and realistically we'll only have 30 mins to talk about the meaty
>> stuff. If we want to go through bullet by bullet, we'll need an entire
>> summit :)
>>
>> Cheers,
>> Armando
>>
>>
>> On 18 October 2015 at 09:14, Armando M.  wrote:
>>
>>> Gal,
>>>
>>> [2] is not meant to be edited by anyone just yet. This will lead to
>>> chaos and an unproductive session. Once the link is out is obvious that
>>> anyone can edit, but welcoming input is a recipe for disaster!
>>>
>>> I appreciate the initiative, but please consider running thoughts by me
>>> for advice.
>>>
>>> Cheers,
>>> Armando
>>>
>>> On 18 October 2015 at 04:09, Gal Sagie  wrote:
>>>
 Hello All,

 In OpenStack Tokyo summit we will have a design summit session for
 containers networking
 and containers orchestration engines integration with Neutron [1].

 Please feel free to edit the session etherpad [2] with relevant topics,
 if you are working
 and have any gaps or needs from Neutron in that area, please share.

 Even if we cant resolve everything in one session, i think it would be
 great to at least understand
 the problems and document them so we can address the needs and
 priorities during the upcoming cycle.

 Thanks
 Gal.

 [1]
 http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
 [2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration


 __
 OpenStack Development Mailing List (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] [ceilometer] ceilometer+ops session

[gord chung]

hi folks,

to followup on an item regarding Ceilometer+ops session at the summit. 
there isn't one explicitly for Ceilometer but there is a monitoring 
session[1] and a billing session[2]. based on the past, these sessions 
tend to focus more on 3rd party tools such as Sensu et al but if free it 
might be worth your time to join as well.


as discussed, we'll be using our ceilometer contributor meet up time to 
discussion the results and feedback from surveys.


[1] 
https://mitakadesignsummit.sched.org/event/2b7a39ba370a9c9f7ab8b7de57ca6188
[2] 
https://mitakadesignsummit.sched.org/event/f72ce4bf2d403aec3357b3af2492ead2


cheers,

--
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-dev] [oslo][log][ossg] Log and OSSG working group session (Re: [oslo] Design Summit Schedule)

[Davanum Srinivas]

Folks,

We've added:
http://mitakadesignsummit.sched.org/event/33df7147d064a37bbffbc44c0ae45824

to discuss topics related to oslo.log/oslo.rootwrap/oslo.privsep etc.
Please let me know if the schedule works.

Thanks,
Dims

On Wed, Oct 14, 2015 at 11:04 AM, Davanum Srinivas 
wrote:

> Folks,
>
> Here's a draft schedule for tokyo summit:
> http://mitakadesignsummit.sched.org/overview/type/oslo
>
> Please let us know if there are any schedule conflicts etc and we can try
> to shuffle these around.
>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>



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

Re: [openstack-dev] [Congress] Congress and Monasca Joint Session at Tokyo Design Summit

[Tim Hinrichs]

Fabio,

I haven't heard back on this so I'm assuming Wed 3:40-4:20 works for you.

Tim


On Wed, Oct 14, 2015 at 10:51 AM Tim Hinrichs  wrote:

> Hi Fabio,
>
> We now have a schedule.  I've tentatively booked you for half of our slot
> Wed 3:40-4:20.  Does that work for your team?  You can find the other
> options at...
>
> https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Congress
>
> Tim
>
>
> On Thu, Oct 1, 2015 at 2:06 PM Fabio Giannetti (fgiannet) <
> fgian...@cisco.com> wrote:
>
>> Thanks a lot Tim.
>> I really appreciate.
>> Fabio
>>
>> From: Tim Hinrichs 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Thursday, October 1, 2015 at 7:40 AM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Congress] Congress and Monasca Joint
>> Session at Tokyo Design Summit
>>
>> Hi Fabio,
>>
>> The Congress team talked this over during our IRC yesterday.  It looks
>> like can meet with your team during one of our meeting slots.  As far as I
>> know the schedule for those meetings hasn't been set.  But once it is I'll
>> reach out (or you can) to discuss the day/time.
>>
>> Tim
>>
>> On Mon, Sep 28, 2015 at 2:51 PM Tim Hinrichs  wrote:
>>
>>>
>>> Hi Fabio: Thanks for reaching out.  We should definitely talk at the
>>> summit.  I don't know if we can devote 1 of the 3 allocated Congress
>>> sessions to Monasca, but we'll talk it over during IRC on Wed and let you
>>> know.  Or do you have a session we could use for the discussion?  In any
>>> case, I'm confident we can make good progress toward integrating Congress
>>> and Monasca in Tokyo.  Monasca sounds interesting--I'm looking forward to
>>> learning more!
>>>
>>> Congress team: if we could all quickly browse the Monasca wiki before
>>> Wed's IRC, that would be great:
>>> https://wiki.openstack.org/wiki/Monasca
>>>
>>> Tim
>>>
>>>
>>>
>>> On Mon, Sep 28, 2015 at 1:50 PM Fabio Giannetti (fgiannet) <
>>> fgian...@cisco.com> wrote:
>>>
 Tim and Congress folks,
   I am writing on behalf of the Monasca community and I would like to
 explore the possibility of holding a joint session during the Tokyo Design
 Summit.
 We would like to explore:

1. how to integrate Monasca with Congress so then Monasca can
provide metrics, logs and event data for policy evaluation/enforcement
2. How to leverage Monasca alarming to automatically notify about
statuses that may imply policy breach
3. How to automatically (if possible) convert policies (or
subparts) into Monasca alarms.

 Please point me to a submission page if I have to create a formal
 proposal for the topic and/or let me know other forms we can interact at
 the Summit.
 Thanks in advance,
 Fabio

 *Fabio Giannetti*
 Cloud Innovation Architect
 Cisco Services
 fgian...@cisco.com
 Phone: *+1 408 527 1134*
 Mobile: *+1 408 854 0020*

 *Cisco Systems, Inc.*
 285 W. Tasman Drive
 San Jose
 California
 95134
 United States
 Cisco.com 

  Think before you print.

 This email may contain confidential and privileged material for the
 sole use of the intended recipient. Any review, use, distribution or
 disclosure by others is strictly prohibited. If you are not the intended
 recipient (or authorized to receive for the recipient), please contact the
 sender by reply email and delete all copies of this message.

 Please click here
  for
 Company Registration Information.


 __
 OpenStack Development Mailing List (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] [cinder] Rolling upgrades - missing pieces

[Dulko, Michal]

Hi all,

One of our priority goals for Liberty was the adoption of
oslo.versionedobjects in order for Cinder to achieve ability to do
rolling upgrades. We weren't successful with that in L, and work got
postponed to Mitaka. I want to highlight remaining work in that topic as
well as other pieces that are still missing in order for Cinder to
support no-downtime-upgrades.

Basically in order to be able to perform such upgrade we need make sure
that our services are compatible between versions. There is a set of
problems that needs to be solved:
* Non-compatible DB migrations (e.g. dropping or altering DB columns).
* Non-compatible RPC API changes (e.g. rename of an argument of a RPC
method).
* Non-compatible changes inside objects/dicts sent over RPC (e.g.
removal of a key there).

Good explanation of how Nova solves these can be found in a series of
posts by Dan Smith - [1][2][3]. I'll walk through all of these.

DB migrations
-
Since Juno no non-compatible DB migration was merged. We may stick to
this approach and allow only additive migrations to be performed (we
probably may allow dropping columns in further release - require that
only two subsequent releases are compatible). This is easy to prevent
using an unit test [4]. Another solution would be to implement online
schema migrations. This was implemented in Nova [5], but is considered
to be unstable and experimental.

RPC API compatibility
-
We're already versioning our RPC layer, but we aren't actually
benefiting from it - we don't support RPC API pinning and don't pay
attention to merge only changes that are backward compatible. This
requires cultural change in reviewing and I think we should discuss the
approach at the Design Summit sprint.

Versioned Objects
-
Right now there's a few outstanding DB-based objects:
* CGSnapshot (in review).
* Volume (partly in review).

You can find patches in [5].

Apart from that I think we need to convert dictionaries sent over RPC to
versioned objects. This would include:
* request_spec (scheduler.rpcapi)
* filter_properites (scheduler.rpcapi)
* capabilities (scheduler.rpcapi) - I'm not sure on this one…

Changing this is required for us to be able to remove or rename fields
in these dictionaries and still be able to provide interoperability of
services working in different versions.

I would love to get some feedback on these thoughts and possibly start a
pre-summit discussion on the whole topic.

[1] http://www.danplanet.com/blog/2015/10/05/upgrades-in-nova-rpc-apis/
[2] http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/
[3] 
http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/
[4] 
https://github.com/openstack/nova/blob/master/nova/tests/unit/db/test_migrations.py#L186-L227
[5] 
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/online-schema-changes.html
[6] 
https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:bp/cinder-objects,n,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] [Neutron] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Murali R]

On Oct 19, 2015 7:31 AM, "Kyle Mestery"  wrote:
>
> On Sun, Oct 18, 2015 at 1:54 PM, Murali R  wrote:
>>
>> Will there be an irc opened for these sessions to join remotely?
>>
> We will have people in the room who will be on IRC, yes, just use
#openstack-neutron. Even better, you can comment on the etherpad live while
the session is going on, which is a good way to attend remotely as well.
>

Thanks Kyle. Will do.
__
OpenStack Development Mailing List (not for 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

[Igor Kalnitsky]

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 
>>> 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 
 >> 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 releases
 >> >> of
 >> >> *stable* branch will be versioned?
 >> >>
 >> >> Let's say 2015.2.0 is Liberty. How 2015.2.1 will be versioned?
 >> >>
 >> >> [1] http://ttx.re/new-versioning.html
 >> >>
 >> >> Thanks,
 >> >> Igor
 >> >>
 >> >>
 >> >> On Thu, Oct 15, 2015 at 6:59 PM, Oleg Gelbukh
 >> >> 
 >> >> wrote:
 >> >> > Hello,
 >> >> >
 >> >> > I would like to highlight a problem that we are now going to
 >> >> > have in
 >> >> > Fuel
 >> >> > regarding versioning of OpenStack.
 >> >> >
 >> >> > As you know, with introduction of the Big Tent policy it was
 >> >> > decided
 >> >> > that
 >> >> > since Liberty dev cycle versioning schema of the whole project
 >> >> > changes.
 >> >> > Year-based versions won't be assigned to individual projects,
 >> >> > nor the
 >> >> > coordinated release is going to have unified number [1].
 >> >> > Individual
 >> >> > projects
 >> >> > will have semver version numbers, while numbering of the release
 >> >> > itself
 >> >> > seems to be dropped.
 >> >> >
 >> >> > However, in Fuel there is a lot of places where we use
 >> >> > year-based
 >> >> > version of
 >> >> > OpenStack release. [2] How are we going to handle this? 

Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor

[Shifali Agrawal]

Thanks for the awesome feedback :)

I got the point of not using project name, thanks Dean for explaining it so
well. We will move ahead as per Monty's suggestion.

On Wed, Oct 14, 2015 at 3:13 PM, Sean Dague  wrote:

> On 10/12/2015 07:55 PM, Dean Troyer wrote:
> > On Mon, Oct 12, 2015 at 5:25 PM, Victoria Martínez de la Cruz
> > >
> > wrote:
> >
> > So, this commands would look like
> >
> > openstack pool-flavor create
> > openstack pool-flavor get
> > openstack pool-flavor delete
> > openstack pool-flavor update
> > openstack pool-flavor list
> >
> >
> > I would strongly suggest leaving the dash out of the resource name:
> >
> > openstack pool flavor create
> > etc
> >
> > Multiple word names have been supported for a long time and the only
> > other plugin I know that has them has a bug against it to remove the
> dash.
>
> So, this might just be me, but I find all the multi word resources to be
> really confusing to use for multiple reasons.
>
> 1) my brain is thinking[options]. When presented
> with it does a lot of thinking  is a verb, oh wait
> it's not, oh wait in this case is it. Is C more verby or B more verby.
> etc etc.
>
> Basically we've removed a very simple rule for how commands look, which
> means more brain power figuring out how each command independently works.
>
> 2) openstack pool -h is an error. That's massively surprising. openstack
> help pool (no such command!).
>
> So while I realize this has been the pattern in the past, it's never
> really worked well for me at least.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for 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.

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 (currently it's too Fuel and Cobbler specific)
>
> Network configuration
> * CRUD api on any entity in the system (in Fuel not all of the data are
> exposed via api,
>   so user has to go and edit entries in db manually)
> * no constraints regarding to network topology (in Fuel there are a lot of
> hardcoded
>   assumptions)
>
> Node hardware discovery
> * should be able to support different source drivers at the same time
>(csv file, fuel-nailgun-agent, CMDB, dhcp, cobbler etc)
> * versioning of HW information (required for life cycle management)
> * notification about changes in hardware or about node statuses
>   (required for life cycle management)
>
> Common requirements for components:
> * every component must follow OpenStack coding standards when
>   we start working upstream after POC (so there shouldn't be a question
>   what to use pecan of flask)
> * Fuel specific interfaces should be implemented as drivers
> * this one is obvious, but currently one of the most problematic parts in
> Fuel,
>   HW gets changed, interface can be replaced, disk can be removed,
>   component should have a way to handle it
>
> Technically speaking, we want to have separate services for every component,
> it is one of the technical ways to force components to have clear
> interfaces.
>
> Other architecture decision which we want to try to solve is extendability,
> currently we have a problem that all of the logic which is related to
> deployment
> data is hardcoded in Nailgun. Plugins should be able to retrieve any data it
> needs from the system, in order to perform plugin deployment, these data
> should
> be retrieved using some interface, and we already have interface where we
> can
> provide stability and versioning, it's REST API. So basically deployment
> should
> consist of two steps first is to retrieve all required data from any source
> it needs,
> and after that send data to the nodes and start deployment.
>
> If you have any questions/suggestion don't hesitate to ask.
>
> 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

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

[Adam Young]

On 10/19/2015 11:53 AM, Fox, Kevin M wrote:

+1.

I think there may be a slight issue with this and Heat, or any other service 
depending on Heat though. It would have to be very carefully through through, 
since Heat acts on behalf of the user as the User him/herself would, so scoping 
may need to interact differently there, then say Nova. Maybe a flag in the 
service catalog saying if the service can be scoped or not?


I think there is a subtlety there you are not making clear.  Why would 
Heat, or any other service not be scoped?  The only rule I am seeing in 
Heat's policy would be


|"service:index": "rule:context_is_admin", 
||http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/policy.json |

But that certainly suffers from the admin-ess problem.  There is 
certainly something strange with the deny rules;  it is trivial to 
bypass this role with a trust.  Somethin needs a second look there anyway.





Thanks,
Kevin

From: Adam Young [ayo...@redhat.com]
Sent: Monday, October 19, 2015 6:53 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [cross-project] Admin

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.

We have a few choices.

1.  Remove Admin from the scoping for projects. Admin is a special role
reserved only for system admins.  Replace project scoped admins with
'manager' or some other comparable role.  This is actually the easiest
solution.

2.  Create a special project for administrative actions.  Cloud admin
users are assigned to this project. Communicate that project Id to the
remote systems.  This is what the policy.v3cloudsample.json file
(http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
recommends.

However, 2 is really not practical without some significant
engineering.  For a new deployment, it would require the following steps.
1) Every single policy file would have to be "templatized"
2) Then deployment mechanism would have to create the admin project, get
the id for it, and string replace it in the policy file.

We could make this happen in Devstack.  The same is true of Puppet,
OSAD, and Fuel.  There would be a lag and the downstream mechanisms
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic
Policy approach.  If OpenStack managed policy deployment via an
inte4rnal mechanism, then adding things like the admin_project_id
becomes trivial.


While I think Dynamic Policy provides a lot of value, I concede that it
is overkill for just substituting in a single value.  The real reason I
am backing off Dynamic Policy for the moment is that we need to better
understand what part of policy should be dynamic and what part should be
static;  we are just getting that clean now.


There is an additional dimension to the admin_project_id issue that
several developers want solved.  In larger deployments, different users
should have administrative capabilities on different endpoints.
Sometimes this is segregated by service (storage admins vs network
admins) and sometimes by region.

Having a special project clearly communicates the intention of RBAC.
But even clearer would be to have the role assignment explicitly on the
catalog item itself.  Which of the following statements would you think
is clearer?


1) Assign Joe the admin role on the project designated to administer
endpoint 0816.
2) 1) Assign Joe the admin role on endpoint 0816.

I think you will agree that it is the latter.  Making this happen would
not be too difficult on the Keystone side, and would require fairly
simple changes on the policy enforcement of the remote projects.  We've
already discussed "endpoint binding of tokens" where an endpoint needs
to know its own ID.  Having a new "scope" in a token that is endpoint_id
would be fairly easy to execute.


One project, though, it that all of the client tooling would need to
change.  Horizon, openstackclient, and keystoneauth would need to handle
"endpoint" as the scope.  This includes third party integrations, which
we do not control.


All 

[openstack-dev] Volunteer for JetBrains License Management

[Andrew Melton]

Hi Devs,


I will be starting a new job in a couple weeks, and as such will be leaving my 
current job and the OpenStack community by the end of this week. That means we 
will need a new representative to manage the Open Source licenses JetBrains has 
given us, and to manage that relationship. So, I am asking if there is anyone 
in the community who would be willing to take this up. In the last year or so 
Jet Brains changed their requirements, and this person will need to be either a 
PTL or a Core developer on an OpenStack project. Please send me a reply if you 
are interested in volunteering for this and we can talk about what it involves.


Thanks!

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

[Fox, Kevin M]

+1.

I think there may be a slight issue with this and Heat, or any other service 
depending on Heat though. It would have to be very carefully through through, 
since Heat acts on behalf of the user as the User him/herself would, so scoping 
may need to interact differently there, then say Nova. Maybe a flag in the 
service catalog saying if the service can be scoped or not?

Thanks,
Kevin

From: Adam Young [ayo...@redhat.com]
Sent: Monday, October 19, 2015 6:53 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [cross-project] Admin

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.

We have a few choices.

1.  Remove Admin from the scoping for projects. Admin is a special role
reserved only for system admins.  Replace project scoped admins with
'manager' or some other comparable role.  This is actually the easiest
solution.

2.  Create a special project for administrative actions.  Cloud admin
users are assigned to this project. Communicate that project Id to the
remote systems.  This is what the policy.v3cloudsample.json file
(http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
recommends.

However, 2 is really not practical without some significant
engineering.  For a new deployment, it would require the following steps.
1) Every single policy file would have to be "templatized"
2) Then deployment mechanism would have to create the admin project, get
the id for it, and string replace it in the policy file.

We could make this happen in Devstack.  The same is true of Puppet,
OSAD, and Fuel.  There would be a lag and the downstream mechanisms
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic
Policy approach.  If OpenStack managed policy deployment via an
inte4rnal mechanism, then adding things like the admin_project_id
becomes trivial.


While I think Dynamic Policy provides a lot of value, I concede that it
is overkill for just substituting in a single value.  The real reason I
am backing off Dynamic Policy for the moment is that we need to better
understand what part of policy should be dynamic and what part should be
static;  we are just getting that clean now.


There is an additional dimension to the admin_project_id issue that
several developers want solved.  In larger deployments, different users
should have administrative capabilities on different endpoints.
Sometimes this is segregated by service (storage admins vs network
admins) and sometimes by region.

Having a special project clearly communicates the intention of RBAC.
But even clearer would be to have the role assignment explicitly on the
catalog item itself.  Which of the following statements would you think
is clearer?


1) Assign Joe the admin role on the project designated to administer
endpoint 0816.
2) 1) Assign Joe the admin role on endpoint 0816.

I think you will agree that it is the latter.  Making this happen would
not be too difficult on the Keystone side, and would require fairly
simple changes on the policy enforcement of the remote projects.  We've
already discussed "endpoint binding of tokens" where an endpoint needs
to know its own ID.  Having a new "scope" in a token that is endpoint_id
would be fairly easy to execute.


One project, though, it that all of the client tooling would need to
change.  Horizon, openstackclient, and keystoneauth would need to handle
"endpoint" as the scope.  This includes third party integrations, which
we do not control.


All of these constraints drive toward a solution where we link the admin
project to the existing endpoint ids.

Make the catalog a separate domain.
Make regions, services, and endpoints projects
Use the rules of Hierarchical Multitenancy to manage the role
assignments for a project.

On the enforcing side, endpoints *must* know their own ID.  They would
have checks that assert token.project_id = self.endpoint_id.

This is the "least magic" approach.  It reuses existing abstractions
without radically altering them.  The chance of a collision between an

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

[Andrew Woodward]

On Mon, Oct 19, 2015 at 9:29 AM Igor Kalnitsky 
wrote:

> 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 it is possible to "spoil" network
> > configuration: when a role get’s assigned to a node, when network
> > changes or network templates are applied.
>
> It won't work that way. What if you enable plugin when all roles are
> assigned? What if you change networks, and now it's not enough IPs? Or
> what if enable plugin that requires 5 VIPs in public network by
> default, and it's not enough. But by using network templates you
> assign this netrole to management network?
>
> From what I can say the proposed approach requires to put checks
> here-and-there around the code. Let's do not overcomplicate things
> without real need.
>
> So let me share my thoughts regarding this issue.
>
> * We shouldn't *allocate* VIPs when we make GET request on network
> configuration handler. It should return only *already allocated* VIPs
> and no more.


I agree, GET handler should not allocate vips, but the problem lies that
VIP's need to already be allocated. They need to be allocated on network
update, or when a node role requiring one is added to the environment. Not
knowing the address until serialization for deployment is too late. The
user needs feedback on the network page. 1) They need to know how many
vip's are on each network (eventually they should be able to set these, but
that is slightly off topic) 2) When saving a change they need to know that
they have ENOUGH IP's for ALL of the currently configured VIPs and Nodes.
Clicking deploy and getting "You don't have enough addresses start over"
with out any feedback on why is not valuable to the user and they go back
to settings pages, count their nodes, and then are "yup, there are enough,
fuel is broken".

Further compacting the issue, now plugins and tasks are going to start to
be able to configure more VIP addresses. In this case it will become even
more confusing as to how many VIP addresses (and from which network) they
come from with out good feedback up front. The only way we can do this is
generating the VIP addresses as soon as we have enough data for them, not
at deployment serialization.



* VIP allocation should be performed when we run deployment.
>
No, see above

> * Before deployment checks should fail, if there's not enough VIPs or
> other resources. So users fix them, and try again.
>
No, see above, its a bad User eXperience (UX) and needs to be stopped. This
is why Roman raised the issue.

> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
> it's safe to return allocated VIPs on that stage.
>
No, Again, this is too late.

>
> So what do you think guys?
>
> Thanks,
> Igor
>
> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko 
> wrote:
> > Hi folks!
> >
> > I’ve been discussing several bugs [1-3] with some folks and noticed that
> they share the same root cause which is that network serialization fails,
> if there’s not enough IP addresses in all available ranges of one of the
> available networks to assign them to all VIPs. There are several possible
> solutions for this issue:
> >
> > a. Not assign addresses to VIPs is a network configuration is being
> serialized for API output.
> > A lot of external tools and modules, i. e., OSTF, rely on that
> information so this relatively small change in Nailgun will require big
> cross-components changes. Therefore this change can only be done as a
> feature but it seems to be the way this issue must be fixed.
> >
> > b. Leave some VIPs without IP addresses
> > If network configuration is generated for API output it is possible to
> leave some VIPs without IP addresses assigned. This will only create more
> mess around Nailgun and bring more issues that it will resolve.
> >
> > c. Check number of IP addresses wherever it is possible to "spoil"
> network configuration: when a role get’s assigned to a node, when network
> changes or network templates are applied.
> >
> >
> > The proposal is to follow [c] as a fast solution and file a blueprint
> for [a]. Opinions?
> >
> >
> > 1 https://bugs.launchpad.net/fuel/+bug/1487996
> > 2 https://bugs.launchpad.net/fuel/+bug/1500394
> > 3 https://bugs.launchpad.net/fuel/+bug/1504572
> >
> >
> > - romcheg
> >
> >
> __
> > OpenStack Development Mailing List (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)
> 

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

[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

[openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query

[Srikanth Vavilapalli]

Hi

I have observed "inf" values for "sum" and "average" fields in a ceilometer 
statistics query on one of my custom meter as shown below. I have also verified 
the samples query for this meter and there are 1544 samples (output shown 
below) with all of them having value as "150.0". So ideally the "Avg" filed 
should be "150.0" in this scenario. Could anyone tell me in what scenario we 
will see these two fields as "inf" in the meter statistics query? Plz let me 
know if you need more details or logs here. Appreciate your help. 

Thanks
Srikanth


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer statistics 
--meter=vcpe.dns.cache.size
++++---+---+-+-+---++++
| Period | Period Start   | Period End | Max   | 
Min   | Avg | Sum | Count | Duration   | Duration Start | Duration 
End   |
++++---+---+-+-+---++++
| 0  | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 
150.0 | inf | inf | 1544  | 231415.588 | 2015-10-17T01:30:24.999000 | 
2015-10-19T17:47:20.587000 |
++++---+---+-+-+---++++


svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer 
sample-list --meter=vcpe.dns.cache.size
+-+-+---++-++
| Resource ID | Name| Type  | Volume | Unit| Timestamp  
|
+-+-+---++-++
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:20.587000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:47:00.048000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:42:20.47 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:41:59.921000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-19T17:37:20.362000 |
.
.
.
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:50:25.499000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:46.255000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:45:25.374000 |
| vcpe-170| vcpe.dns.cache.size | gauge | 150.0  | entries | 
2015-10-17T01:40:46.131000 |

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

Re: [openstack-dev] Volunteer for JetBrains License Management

[Andrew Melton]

Hey Devs,


Thanks again to those who expressed interest in taking this over! I've found a 
Core who was willing to take this over, Swapnil Kulkarni. For JetBrains 
licenses going forward please contact him at 'm...@coolsvap.net'.


Thanks!

Andrew


From: Andrew Melton 
Sent: Monday, October 19, 2015 11:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Volunteer for JetBrains License Management


Hi Devs,


I will be starting a new job in a couple weeks, and as such will be leaving my 
current job and the OpenStack community by the end of this week. That means we 
will need a new representative to manage the Open Source licenses JetBrains has 
given us, and to manage that relationship. So, I am asking if there is anyone 
in the community who would be willing to take this up. In the last year or so 
Jet Brains changed their requirements, and this person will need to be either a 
PTL or a Core developer on an OpenStack project. Please send me a reply if you 
are interested in volunteering for this and we can talk about what it involves.


Thanks!

Andrew
__
OpenStack Development Mailing List (not for 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] Testing before switching to upstream librarian

[Sergey Kolekonov]

Hi,

I agree with Ivan. Getting rid of forks and moving to puppet-librarian is
complicated work and such problems are nearly unavoidable. It's hard to
cover all possible corner cases with regular tests.
openstacklib module provides basic functionality for many OpenStack
modules, so reverting it to Kilo code means breaking the whole Liberty
deployment.
Let's don't block development process and merge all lost fixes.

Thanks Matthew for reporting this issue.

On Mon, Oct 19, 2015 at 10:10 PM, Ivan Berezovskiy <
iberezovs...@mirantis.com> wrote:

> Hi,
>
> First of all, I want to mention (I don't blame anyone), that two patchsets
> in bug description
> ([0], [1]) were not merged into upstream puppet-openstacklib module (and
> commit
> messages don't contain links to upstream review). I see only one proposed
> patch [2]
> from Dmitry Ilyin, which was abandoned at Sep 18. Now it's restored and
> those issues should be fixed using it.
>
> Second, our patches (moving to librarian) were tested several times under
> Fuel CI jobs,
> on BVTs, smoke_neutron tests with Kilo and Liberty code. Unfortunately, we
> didn't find
> problems with deployment.
>
> Third, two weeks passed after merging of our patches for librarian, and
> only now
> we are speaking about regressions.
>
> Patch [2] covers missing two commits [0], [1], that's why I suggest to get
> it merged
> and then recheck issues, because it's very late for reverting.
>
>
> [0] - https://review.openstack.org/#/c/219668/
> [1] - https://review.openstack.org/#/c/223676/
> [2] - https://review.openstack.org/#/c/220224/
>
> 2015-10-19 20:59 GMT+03:00 Sergii Golovatiuk :
>
>> Hi,
>>
>> The policy should be revert, IMHO. cherry-pick doesn't guarantee the
>> consistency, so it will take more time... Also this way gives time to write
>> tests to exclude the regression in future.
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Oct 19, 2015 at 6:52 PM, Matthew Mosesohn > > wrote:
>>
>>> Hi Fuelers,
>>>
>>> It seems we have a regression on two critical bugs because of switching
>>> Fuel to puppet-openstacklib:
>>> https://bugs.launchpad.net/fuel/+bug/1507685
>>>
>>> This regressed to patches that were in Fuel Library that addressed two
>>> bugs marked as Critical.
>>>
>>> We should improve the acceptance criteria for moving to upstream modules
>>> to ensure no bugs are regressed that relate to the particular Puppet module
>>> being migrated.
>>>
>>> Secondly, what should our policy be? Revert the switch to upstream
>>> module? Or just work on cherry-picking the appropriate fixes?
>>>
>>> Best Regards,
>>> Matthew Mosesohn
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Thanks, Ivan Berezovskiy
> MOS Puppet Team Lead
> at Mirantis 
>
> slack: iberezovskiy
> skype: bouhforever
> phone: + 7-960-343-42-46
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Sergey Kolekonov
__
OpenStack Development Mailing List (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,

Is it possible to switch Group management session  to Thursday?   I
have a techtalk at 2:30pm on Wednesday and it makes it very tight for me
and Shiv to attend the group management at 2:50 pm.  Since Shiv and myself
are the proposer for the group management session, we want to be able to
attend this discussion.  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] [app-catalog] IRC Meeting Thursday November 5th at 17:00 UTC

[Christopher Aedo]

Hello all!  Due to the summit we will cancel the next two weeks of IRC
meetings for the App Catalog.

The next meeting will be Thursday November 5th at 17:00UTC on
#openstack-meeting-3

The agenda can be found here:
https://wiki.openstack.org/wiki/Meetings/app-catalog

I expect we'll have a lot to talk about after Tokyo so expect some
agenda items to be updated before the meeting.

Hopefully I'll see most of you in Tokyo!

-Christopher

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

Re: [openstack-dev] [cinder] Rolling upgrades - missing pieces

[Dulko, Michal]

On Mon, 2015-10-19 at 11:19 -0500, Sean McGinnis wrote:
> On Mon, Oct 19, 2015 at 03:10:16PM +, Dulko, Michal wrote:
> > Hi all,
> > 
> > One of our priority goals for Liberty was the adoption of
> > oslo.versionedobjects in order for Cinder to achieve ability to do
> > rolling upgrades. We weren't successful with that in L, and work got
> > postponed to Mitaka. I want to highlight remaining work in that topic as
> > well as other pieces that are still missing in order for Cinder to
> > support no-downtime-upgrades.
> > 
> 
> > 
> > Changing this is required for us to be able to remove or rename fields
> > in these dictionaries and still be able to provide interoperability of
> > services working in different versions.
> > 
> > I would love to get some feedback on these thoughts and possibly start a
> > pre-summit discussion on the whole topic.
> 
> Thanks for bringing this up Michal. Will you be around for the weekly
> meeting this week? It would be great if we could get this on the agenda
> just to make sure everyone is aware of it. 
> 
> That may help to make sure more folks have had a chance to think about
> this, even briefly, before the design summit.
> 
> Thanks!
> Sean

I've added an item to the agenda. This is a big topic, but I'll try to
prepare some general questions to shape the discussion a little.
__
OpenStack Development Mailing List (not for 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] Driver documentation in Ironic

[Jim Rollenhagen]

On Thu, Oct 15, 2015 at 09:23:18PM +0530, Ramakrishnan G wrote:
> Hi All,
> 
> This mail is related to driver-specific documentation in Ironic.
> 
> First a bit of context.  I work on iLO drivers in Ironic. Our team would
> like to document both Ironic driver related stuff (which is related to
> Ironic) and hardware related stuff like tested platforms, firmware
> information, firmware issues, etc (which is not related to Ironic) in the
> documentation. Today we keep it at two places - ironic related one in
> ironic tree and (ironic + non-ironic) related one in wiki. It's hard for
> both people who work on documentation and people who read this
> documentation to update/refer information in two places.  Hence we decided
> to raise the review [0] to move the content completely to wiki.  It got
> mixed response.  While some people are okay with it, but some others
> (including our ptl :)) feel it's worth putting it in-tree and try to
> address the problems.
> 
> So what all are the problems ?
> 1) Ability to update the driver documentation not-related to Ironic easily
> without waiting.
> 2) To save some core reviewers time who might not be familiar with the
> hardware.
> 
> To solve the actual problem of updating the documentation easily while
> keeping it in-tree, I checked with infra folks if a subset of a repository
> can be +2ed/+Aed by another group.  They confirmed it's not possible
> (unless there was a communication gap in that conversation, folks can
> correct me if I am wrong).
> 
> The following are the options that I can think of to address this:
> 
> 1) Easy approvals for patches solely related to driver documentation. Once
> the driver team feels the documentation is ready, it can be +Aed by a core
> team member skipping the normal process of review. Of course, fixing any
> comments that come by, but not waiting for the normal rule of 2x+2s.
> 
> 2) A separate repository for driver documentation controller by driver
> developers (a bad idea ??)
> 
> 3) Allow to push driver documentation to wiki for those who wish to.
> 
> Thoughts ???

We talked about this in our IRC meeting as well, and there isn't really
a good answer for "allow driver authors to merge their own docs ASAP".

I'd like to see some examples of docs patches that: 1) took too long to
merge, and 2) what problems that caused.

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

Re: [openstack-dev] [ironic] [horizon] ironic panels

[Fox, Kevin M]

The app catalog ui is using Angular almost exclusively. See: 
https://github.com/openstack/app-catalog-ui

The Horizon developers have been quite supportive of using Angular in Horizon 
plugins.

I think its been more of an issue migrating Python Horizion views to Angular in 
Horizon itself, not that Horizon isn't supporting Angular yet.

Thanks,
Kevin

From: Beth Elwell [e.r.elw...@gmail.com]
Sent: Monday, October 19, 2015 11:05 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ironic] [horizon] ironic panels

Hi all,

I am currently in the process of writing an Ironic panel in Horizon
upstream. It was originally intended for this panel to be written in
Angular JS, however, as I understand, no horizon angular work will
merge for several months, and 2-3 panels (of which ironic is not one)
are being moved to the feature branch to iterate on the design pattern
that they want to use to implement the angular.

With regard to the ironic panel, this means that in order to implement
it in angular, it will take weeks or perhaps months to merge and even
when it does, it may well need to be rewritten to follow design patterns
being set at the moment.

Therefore I propose that I continue to develop this as a Horizon python
panel as a short term solution to allow a UI to exist for our users of
Ironic ASAP and longer term make use of the ironic webclient and the
work that krotscheck is currently doing on that.

I would appreciate feedback with regard to whether the ironic community
are happy for me to continue on with developing a horizon panel or would
like me to work on an angular panel.

Many thanks,
Beth Elwell


__
OpenStack Development Mailing List (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] [openstack-operators][Tacker] BoF on NFV Orchestration using Tacker

[Sridhar Ramaswamy]

Operators, Devs:

Tacker team is soliciting inputs towards building the next set of features
in the area of NFV Orchestration. We have the following Birds-of-a-Feather
session to get together on this subject,

When: Tuesday Oct 27, 2015
Where: OpenStack Tokyo Summit
Link: http://sched.co/4MZc

Some of the top roadmap items in our pipleline are,

- Forwarding Graph support using Service Function Chaining
- VNF placement across multi-VIM and other placement strategies
- Orchestrating NF across Physical, Virtual (and Containers ??)

We would love to hear your thoughts on these and possibly others. Please
feel free to forward this to other organizations of interest which could
provide inputs.

thanks!
- Tacker team
__
OpenStack Development Mailing List (not for 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] Testing before switching to upstream librarian

[Ivan Berezovskiy]

Hi,

First of all, I want to mention (I don't blame anyone), that two patchsets
in bug description
([0], [1]) were not merged into upstream puppet-openstacklib module (and
commit
messages don't contain links to upstream review). I see only one proposed
patch [2]
from Dmitry Ilyin, which was abandoned at Sep 18. Now it's restored and
those issues should be fixed using it.

Second, our patches (moving to librarian) were tested several times under
Fuel CI jobs,
on BVTs, smoke_neutron tests with Kilo and Liberty code. Unfortunately, we
didn't find
problems with deployment.

Third, two weeks passed after merging of our patches for librarian, and
only now
we are speaking about regressions.

Patch [2] covers missing two commits [0], [1], that's why I suggest to get
it merged
and then recheck issues, because it's very late for reverting.


[0] - https://review.openstack.org/#/c/219668/
[1] - https://review.openstack.org/#/c/223676/
[2] - https://review.openstack.org/#/c/220224/

2015-10-19 20:59 GMT+03:00 Sergii Golovatiuk :

> Hi,
>
> The policy should be revert, IMHO. cherry-pick doesn't guarantee the
> consistency, so it will take more time... Also this way gives time to write
> tests to exclude the regression in future.
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Oct 19, 2015 at 6:52 PM, Matthew Mosesohn 
> wrote:
>
>> Hi Fuelers,
>>
>> It seems we have a regression on two critical bugs because of switching
>> Fuel to puppet-openstacklib:
>> https://bugs.launchpad.net/fuel/+bug/1507685
>>
>> This regressed to patches that were in Fuel Library that addressed two
>> bugs marked as Critical.
>>
>> We should improve the acceptance criteria for moving to upstream modules
>> to ensure no bugs are regressed that relate to the particular Puppet module
>> being migrated.
>>
>> Secondly, what should our policy be? Revert the switch to upstream
>> module? Or just work on cherry-picking the appropriate fixes?
>>
>> Best Regards,
>> Matthew Mosesohn
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis 

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46
__
OpenStack Development Mailing List (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] [horizon] ironic panels

[Beth Elwell]

Hi all,

I am currently in the process of writing an Ironic panel in Horizon
upstream. It was originally intended for this panel to be written in
Angular JS, however, as I understand, no horizon angular work will
merge for several months, and 2-3 panels (of which ironic is not one)
are being moved to the feature branch to iterate on the design pattern
that they want to use to implement the angular.

With regard to the ironic panel, this means that in order to implement
it in angular, it will take weeks or perhaps months to merge and even
when it does, it may well need to be rewritten to follow design patterns
being set at the moment.

Therefore I propose that I continue to develop this as a Horizon python
panel as a short term solution to allow a UI to exist for our users of
Ironic ASAP and longer term make use of the ironic webclient and the
work that krotscheck is currently doing on that.

I would appreciate feedback with regard to whether the ironic community
are happy for me to continue on with developing a horizon panel or would
like me to work on an angular panel.

Many thanks,
Beth Elwell


__
OpenStack Development Mailing List (not for 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] Testing before switching to upstream librarian

[Sergii Golovatiuk]

Hi,

The policy should be revert, IMHO. cherry-pick doesn't guarantee the
consistency, so it will take more time... Also this way gives time to write
tests to exclude the regression in future.


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

On Mon, Oct 19, 2015 at 6:52 PM, Matthew Mosesohn 
wrote:

> Hi Fuelers,
>
> It seems we have a regression on two critical bugs because of switching
> Fuel to puppet-openstacklib:
> https://bugs.launchpad.net/fuel/+bug/1507685
>
> This regressed to patches that were in Fuel Library that addressed two
> bugs marked as Critical.
>
> We should improve the acceptance criteria for moving to upstream modules
> to ensure no bugs are regressed that relate to the particular Puppet module
> being migrated.
>
> Secondly, what should our policy be? Revert the switch to upstream module?
> Or just work on cherry-picking the appropriate fixes?
>
> Best Regards,
> Matthew Mosesohn
>
> __
> OpenStack Development Mailing List (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] [designate] Update on Meetings + Code Freeze post Summit

[Hayes, Graham]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

Just a reminder that at the last IRC meeting [0] we decided a few things

1 - We are skipping 2 weeks or IRC meetings

2 - Due to the "big rename" [1] we are implementing a code freeze from
the 10th -> 13th of November.

The core team should be online on Monday the 9th to push as many
patches through as possible. All patches proposed after the 10th that
are not in the correct topic will be getting a procedural -2.

This will be lifted on the 13th, but nearly all patches will need
manual rebasing post rename.

I realise that this may cause some issues, but this is a rename we
really need do. We have had a host of "interesting" code to work around
it, and I think now that the v1 API is actually depricated, we can
start.

0 -
http://eavesdrop.openstack.org/meetings/designate/2015/designate.2015-10
- -14-17.00.html

1 - https://blueprints.launchpad.net/designate/+spec/the-big-rename

If there is any questions, give me a shout.

Graham

- -- 
Graham Hayes
Software Engineer
DNS as a Service

GPG Key: 7D28E972


graham.ha...@hpe.com
Dublin,
Ireland

HP

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWJTTzAAoJEPRBUqpJBgIiZcwH/1QrKy9y8L3sVKvzwPyNzd1Z
y6soZKt8F6vd2AAj5eQ21x5ihH/oRr9J96Y0Ssm6jakNv5eoAp9UPQn/5OrzD+mW
HabskjEHnCFvMvTx8cd3CSc8UJJBpi96MhxXWzfjZ8FJTq+e84w6YaeAvZX+kVKv
8gj9iCxbvWGIteLGu9qJaiLfQvKjGwAtYCLwh+Nte9Clovnt3azTR5GUnMFxx7xv
tWIl82hSVLQQZpfTFxy6k+04EtXEhF5lafe/njmOTQ+Ee7toXnzLJNGt64N8538C
QSNQ0KsO2DG2PYXF33H9AIVsVPwh1fU7Nh1eof5jr5yBDoY5lg1DDzi3o8XW26c=
=uiqF
-END PGP SIGNATURE-

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

Re: [openstack-dev] [ironic] [horizon] ironic panels

[Jim Rollenhagen]

On Mon, Oct 19, 2015 at 07:05:04PM +0100, Beth Elwell wrote:
> 
> Hi all,
> 
> I am currently in the process of writing an Ironic panel in Horizon
> upstream. It was originally intended for this panel to be written in
> Angular JS, however, as I understand, no horizon angular work will
> merge for several months, and 2-3 panels (of which ironic is not one)
> are being moved to the feature branch to iterate on the design pattern
> that they want to use to implement the angular.
> 
> With regard to the ironic panel, this means that in order to implement
> it in angular, it will take weeks or perhaps months to merge and even
> when it does, it may well need to be rewritten to follow design patterns
> being set at the moment.
> 
> Therefore I propose that I continue to develop this as a Horizon python
> panel as a short term solution to allow a UI to exist for our users of
> Ironic ASAP and longer term make use of the ironic webclient and the
> work that krotscheck is currently doing on that.
> 
> I would appreciate feedback with regard to whether the ironic community
> are happy for me to continue on with developing a horizon panel or would
> like me to work on an angular panel.

In general, I like the idea of "get a web interface to users quickly",
and in that spirit I think building a horizon panel is the right thing
to do.

I do love the webclient work; I think it's great. However, considering
that (as far as I know) there's only two people working on Ironic web
interfaces, is it valuable to be working on two different web interfaces
right now? In the worst case:

* horizon panel will be built
* webclient will also be built
* horizon will figure out angular stuff
* webclient will be re-written to work with horizon
* webclient will likely take significant time to merge into horizon
* old horizon panel will be deprecated
* (in time) old horizon panel will be removed

And in the best case, only the rewrite step is skipped, and maybe the
merge into horizon won't take long. There's also a question about how
much different the two are, and how large of a leap that is for users.

That seems like a lot of extra effort and maintenance for an entire
team; let alone two people. So I question if it's worth working on the
webclient, or punting on that until horizon is ready, and then
refactoring the horizon panel into angular.

Is there a clear benefit to having both worked on in parallel?

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

Re: [openstack-dev] [Fuel] Core Reviewers groups restructure

[Dmitry Borodaenko]

Now that OpenStack Infra team has completed the stackforge namespace
retirement and merged our ACL update [0], the rest of core reviewers
cleanup is done:

- creating tags and branches is now restricted to fuel-release group [1]
- fuel-specs-core is populated as per proposal quoted below [2]

[0] https://review.openstack.org/230195
[1] https://review.openstack.org/#/admin/groups/1128,members
[2] https://review.openstack.org/#/admin/groups/1129,members

If you are a member of a fuel-*-core group, please check the list of
your group members now and make sure that fuel-release group is included
in your core group as a group (not as individual members).

All Fuel related gerrit groups can be found with this filter [3]:

[3] https://review.openstack.org/#/admin/groups/?filter=fuel-

Thank you,

-- 
Dmitry Borodaenko


On Wed, Oct 07, 2015 at 05:35:48PM -0700, Dmitry Borodaenko wrote:
> On Wed, Oct 07, 2015 at 02:04:52PM -0700, Dmitry Borodaenko wrote:
> > While we're waiting for openstack-infra team to finish the stackforge
> > migration and review our ACL changes, I implemented the rest of the
> > changes agreed in this thread:
> > 
> > - Fuel-core group removed everywhere.
> > 
> > - Per-project core groups populated with individual reviewers as quoted
> >   below. Exceptions:
> > 
> >   - Dennis Dmitriev was approved as core in fuel-qa, fuel-devops, and
> > fuel-ostf after this thread was started;
> 
> Correction: I meant fuel-qa and fuel-devops here, not fuel-ostf.
> 
> >   - fuel-upgrades already excludes fuel-core so I couldn't modify it,
> > and the current list doesn't match Mike's email. It is up to current
> > cores [0] to bring it up to date.
> > 
> > [0] https://review.openstack.org/#/admin/groups/1004,members
> > 
> > fuel-specs and fuel-*-release groups will have to wait until ACL update
> > is merged (i.e. after October 17).
> > 
> > -- 
> > Dmitry Borodaenko
> > 
> > On Thu, Oct 01, 2015 at 03:59:47PM -0700, Dmitry Borodaenko wrote:
> > > This commit brings Fuel ACLs in sync with each other and in line with
> > > the agreement on this thread:
> > > https://review.openstack.org/230195
> > > 
> > > Please review carefully. Note that I intentionally didn't touch any of
> > > the plugins ACLs, primarily to save time for us and the
> > > openstack-infra team until after the stackforge->openstack namespace
> > > migration.
> > > 
> > > On Mon, Sep 21, 2015 at 4:17 PM, Mike Scherbakov
> > >  wrote:
> > > > Thanks guys.
> > > > So for fuel-octane then there are no actions needed.
> > > >
> > > > For fuel-agent-core group [1], looks like we are already good (it 
> > > > doesn't
> > > > have fuel-core group nested). But it would need to include fuel-infra 
> > > > group
> > > > and remove Aleksandra Fedorova (she will be a part of fuel-infra group).
> > > >
> > > > python-fuel-client-core [2] is good as well (no nested fuel-core). 
> > > > However,
> > > > there is another group python-fuelclient-release [3], which has to be
> > > > eliminated, and main python-fuelclient-core would just have fuel-infra 
> > > > group
> > > > included for maintenance purposes.
> > > >
> > > > [1] https://review.openstack.org/#/admin/groups/995,members
> > > > [2] https://review.openstack.org/#/admin/groups/551,members
> > > > [3] https://review.openstack.org/#/admin/groups/552,members
> > > >
> > > >
> > > > On Mon, Sep 21, 2015 at 11:06 AM Oleg Gelbukh  
> > > > wrote:
> > > >>
> > > >> FYI, we have a separate core group for stackforge/fuel-octane 
> > > >> repository
> > > >> [1].
> > > >>
> > > >> I'm supporting the move to modularization of Fuel with cleaner 
> > > >> separation
> > > >> of authority and better defined interfaces. Thus, I'm +1 to such a 
> > > >> change as
> > > >> a part of that move.
> > > >>
> > > >> [1] https://review.openstack.org/#/admin/groups/1020,members
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Oleg Gelbukh
> > > >>
> > > >> On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov
> > > >>  wrote:
> > > >>>
> > > >>> Hi all,
> > > >>> as of my larger proposal on improvements to code review workflow [1], 
> > > >>> we
> > > >>> need to have cores for repositories, not for the whole Fuel. It is 
> > > >>> the path
> > > >>> we are taking for a while, and new core reviewers added to specific 
> > > >>> repos
> > > >>> only. Now we need to complete this work.
> > > >>>
> > > >>> My proposal is:
> > > >>>
> > > >>> Get rid of one common fuel-core [2] group, members of which can merge
> > > >>> code anywhere in Fuel. Some members of this group may cover a couple 
> > > >>> of
> > > >>> repositories, but can't really be cores in all repos.
> > > >>> Extend existing groups, such as fuel-library [3], with members from
> > > >>> fuel-core who are keeping up with large number of reviews / merges. 
> > > >>> This
> > > >>> data can be queried at Stackalytics.
> > > >>> Establish a new group "fuel-infra", and 

[openstack-dev] [Neutron] Mitaka Design Summit schedule for Neutron

[Armando M.]

Hi folks,

The schedule for the Neutron project is published in [1]. We are still
going through/ironing out some details, but for the most part (especially
the order of sessions) we should be all set.

See you in Tokyo!

Cheers,
Armando

[1] http://mitakadesignsummit.sched.org/overview/type/neutron
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] [neutron] Enforce port/portgroup MAC uniqueness constraint

[William Stevenson]

Hi,

In reference to comments on a patchset[1], port/portgroup addresses
should be unique. Please also see the irc log[1] which includes
earlier discussion regarding rationale.

Q: How can we enforce this uniqueness across tables?


[1] 
https://review.openstack.org/#/c/206232/26/ironic/db/sqlalchemy/alembic/versions/5ea1b0d310e_added_port_group_table_and_altered_ports.py
[2] http://ix.io/luF/irc


__
OpenStack Development Mailing List (not for 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 Mon, Oct 19, 2015 at 02:33:57PM -0700, Wan-yen Hsu wrote:
> Hi Jim,
> 
> Is it possible to switch Group management session  to Thursday?   I
> have a techtalk at 2:30pm on Wednesday and it makes it very tight for me
> and Shiv to attend the group management at 2:50 pm.  Since Shiv and myself
> are the proposer for the group management session, we want to be able to
> attend this discussion.  Thanks!

Your talk is 2:00-2:40, correct? The reason I scheduled it at 2:50 is
because of this talk. The only other place I could put it is Thursday at
11:00, however some operators expressed more interest in the driver API
session, and they have Wednesday sessions going on.

I'd prefer if you could just walk quickly (run?) between these two - if
you think that is impossible I may be able to switch them. Let me know. :)

// 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] [Horizon] Mitaka schedule and etherpads

[David Lyle]

The schedule for Horizon is published [1] and the initial etherpads
are linked [2]. Happy typing.

Looking forward to seeing everyone next week.

David

[1] http://mitakadesignsummit.sched.org/overview/type/horizon
[2] https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Horizon

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

Re: [openstack-dev] [neutron][calico] networking-calico 1.0.0

[Carl Baldwin]

Great work Calico!

Count me in when you have project meetings, I'd like to keep up.

Carl
On Oct 16, 2015 6:21 AM, "Neil Jerram"  wrote:

> I'm happy to announce the first release of networking-calico.  As it
> says at http://docs.openstack.org/developer/networking-calico/:
>
>   networking-calico is the Neutron ‘stadium’ sub-project that provides
>   ‘Calico’ connectivity and security in an OpenStack/Neutron cloud.
>
>   Calico [1] uses IP routing to provide connectivity between the
>   workloads in a data center that provide or use IP-based services -
>   whether VMs, containers or bare metal appliances; and iptables, to
>   impose any desired fine-grained security policy between those
>   workloads. Calico thus differs from most other Neutron backends,
>   which use bridging and tunneling to simulate L2-level connectivity
>   between the VMs attached to a Neutron network.
>
>   [1] http://www.projectcalico.org
>
> Release notes, as at
> https://launchpad.net/networking-calico/+milestone/1.0.0:
>
>   First release of networking-calico.
>
>   - Calico integration with vanilla Liberty OpenStack (i.e. without
> requiring any Calico-specific patching).
>
>   - DevStack plugin that makes it easy to set up and use a single or
> multi-node Calico/DevStack cluster.
>
>   For documentation, please see:
>
>   - http://docs.openstack.org/developer/networking-calico/, for
> networking-calico as a whole
>
>   - http://docs.openstack.org/developer/networking-calico/devstack.html,
> for how to use the DevStack plugin.
>
> Please do let me know of any feedback.  In the coming weeks I will aim
> to establish a regular IRC meeting for this project, so as to widen
> participation; so it would be good to know who would be interested in that.
>
> Many thanks,
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for 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]

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-dev] [stable] Need group membership change for manila-stable-maint

[Ben Swartzlander]

I would like the manila-core group added as an included group in 
manila-stable-maint. I'm not sure what the right procedure is so I'm 
asking here.


-Ben Swartzlander


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

[openstack-dev] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

(diff with Oct 12, no diff for inspector)
- Open: 150 (+7). 3 new (+1), 41 in progress (+5), 2 critical (+2), 11 high
(-1) and 11 incomplete (+1)
- Nova bugs with Ironic tag: 25 (+1). 2 new (+1), 0 critical, 0 high
- Inspector bugs: 15 (+3). 0 new, 0 critical, 7 high (+3)


Neutron/Ironic work (jroll)

- Spec for nova work is up: https://review.openstack.org/237067
- Open question: how do we enforce uniqueness between port.address and
portgroup.address?
- reviews in progress


Testing/Quality (jlvillal/lekha/krtaylor)

- started work on patch to stand-up and tear-down ironic-api and
ironic-conductor services for functional testing. Code borrowed from Glance
project.
- parent patch proposed to allow running ironic-api and ironic-conductor
with "python -m ironic.cmd.api" or "python -m ironic.cmd.conductor"


Inspector (dtansur)
===
- Releasing ironic-inspector 2.2.2 this week due to a couple of bugs:
- https://bugs.launchpad.net/ironic-inspector/+bug/1506419
- https://bugs.launchpad.net/ironic-inspector/+bug/1506160


webclient (krotscheck / betherly)
=
- Update on the ironic panel in horizon: If we continue writing this in
angular it will NOT be merged for months because of the upstream battle on
horizon to work out angular standards. And even when it gets through the
waiting period it will likely have to change to adopt all the changes made
to the way angular should be written in horizon. Are you happy for me to
move ahead with this as a python panel and a good looking front end as a
temporary measure to using the webclient and working out how to improve
general front end in the longer term?


Drivers
==

iRMC (naohirot)
--
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)



Until the week of Nov. 9,
--ruby

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

[openstack-dev] [kolla] Mitaka Summit Schedule

[Steven Dake (stdake)]

Kollians,

I have produced the Mitaka design sessions based upon our previous voting about 
a month ago into the following schedule.  I would update sched.org, but it is 
returning an error 500 presently.  Once it is active again, I'll make sure the 
detailed schedule is placed into sched.org.

https://etherpad.openstack.org/p/kolla-mitaka-all-sessions
__
OpenStack Development Mailing List (not for 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

[Mike Scherbakov]

Thanks Vladimir.
This is very important work, I'd say. I'd split it into two parts:

   1. Have some store where you'd dump data from serializers. Hiera should
   be able to read easily directly from this store.
   2. Refactor serializers so to get rid of single python method which
   creates data for multiple OpenStack components, and allow deployment
   engineers to easily modify code of particular piece

For #1, it is important to think broadly. We want this store to be used by
other tools which users may have (Puppet Master, Ansible, etc.) as a source
data, and so that Fuel & other tools can coexist on the same env if really
needed (even though I'd ideally try to avoid it).
We need to have an abstraction layer there, so that we can have drivers for
key-value store and for such things as Zookeeper, for instance, in the
future. I think we need to address #1 in the first order, before going to
#2 (if we can't do it in parallel).

For #2, I think we need to consider flexibility. What if we use Ansible, or
container for some of our services? So we need to think where we can put
these per-component / per-task serializers, so those can be used for both
Puppet module & something different.

Also, it's interesting problem from the execution point of view. Do we run
serialization on Fuel Master side or on slave nodes, where we install
OpenStack? I see some issues with running it on OpenStack nodes, even
though I like an idea of load distribution, etc. For instance, if you run
almost all graph, and then the last task in the graph runs corresponding
serializer - and there is a Python exception for whatever reason (user
input leads to bug in calculation). You could get it right a way, if you
tried to calculate it before overall deployment - but now you've been
waiting deployment to be almost done to catch it.

Thank you,

On Fri, Oct 16, 2015 at 9:22 AM Vladimir Kuklin 
wrote:

> Hey, Fuelers
>
> TL;DR This email is about how to make
>
> * Intro
> I want to bring up one of the important topics on how to make Fuel more
> flexible. Some of you know that we have been discussing means of doing this
> internally and now it is time to share these thoughts with all of you.
>
> As you could know per Evgeniy Li's message [0] we are looking forward
> splitting Fuel (specifically it's Fuel-Web) part into set of microservices
> each one serving their own purpose like networking configuration,
> partitioning, etc.
>
>
> And while we are working on this it seems that we need to get rid of
> so-called Nailgun serializers that are put too close to business logic
> engine, that have a lot of duplicating attributes; you are not able to
> easily modify or extend them; you are not able to change their behaviour
> even when Fuel Library is capable of doing so - everything is hardcoded in
> Nailgun code without clear separation between business logic and actual
> deployment workflow data generation and orchestration.
>
> Let me give you an example:
>
> * Case A. Replace Linux bridges with OVS bridges by default
>
> We all know that we removed OVS as much as possible from our reference
> architecture due to its buginess. Imagine a situation when someone
> magically fixed OVS and wants to use it as a provider for generic bonds and
> bridge. It actually means that he needs to set default provider in
> network_scheme for l23network puppet module to 'ovs' instead of 'lnx'.
> Imagine, he has put this magical OVS into a package and created a plugin.
> The problem here will be that he needs to override what network serializer
> is sending to the nodes.
>
> But the problem here is that he cannot do it without editing Nailgun code
> or override this serializer in any way.
>
> * Case B. Make Swift Partitions Known to Fuel Library
>
> Imagine, you altered the way you partition your disk in Nailgun. You
> created a special role for swift disks which should occupy the whole disk.
> In this case you should be able to get this info from api and feed it to
> swift deployment task. But it is not so easy - this stuff is still
> hardcoded in deployment serializers like {mp} field of nodes array of
> hashes.
>
> * Proposed solution
>
> In order to tackle this I propose to extract these so called serializers
> (see links [1] and [2]) and put them closer to library. You can see that
> half of the code is actually duplicated for deployment and provsioning
> serializers and there is actually no inheritance of common code betwen
> them. If you want to introduce new attribute and put it into astute.yaml,
> you will need to rewrite Nailgun code. This is not very
> deployment/sysop/sysadmin engineer-friendly. Essentially, the proposal is
> to introduce a library of such `serializers` (I would like to call them
> translators actually) which could leverage inheritance, polymorphism and
> incapsulation pretty much in OOP mode but with ability for deployment
> engineers to apply versioning to serializers and allow each particular task
> to work 

Re: [openstack-dev] [fuel] PTL & Component Leads elections

[Mike Scherbakov]

Congrats Igor!

Sergey - thanks for help.

On Mon, Oct 19, 2015 at 2:48 AM Sergey Lukjanov 
wrote:

> Hi folks,
>
> it's time to start voting for the component leads.
>
> There was only one candidate for the Fuel Python Component Lead, so, no
> need for voting. Congrats to Igor Kalnitsky!
>
> For the Fuel Library Component Lead we have two candidates and you should
> receive an email with title "Poll: Fuel Library Component Lead Elections
> Fall 2015" soon to vote for them. Please, don't share / forward this email,
> it contains your personal unique token for the voting.
>
> The estimated date for the voting end is Oct 22.
>
> Thanks.
>
> On Tue, Oct 13, 2015 at 4:05 PM, Tomasz Napierala  > wrote:
>
>> Congrats Dmitry! Well deserved.
>>
>>
>> > On 09 Oct 2015, at 19:13, Mike Scherbakov 
>> wrote:
>> >
>> > Congratulations to Dmitry!
>> > Now you are officially titled with PTL.
>> > It won't be easy, but we will support you!
>> >
>> > 118 contributors voted. Thanks everyone! Thank you Sergey for
>> organizing elections for us.
>> >
>> > On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov 
>> wrote:
>> > Voting period ended and so we have an officially selected Fuel PTL -
>> DB. Congrats!
>> >
>> > Poll results & details -
>> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0
>> >
>> > Let's start proposing candidates for the component lead positions!
>> >
>> > On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov <
>> slukja...@mirantis.com> wrote:
>> > Hi folks,
>> >
>> > I've just setup the voting system and you should start receiving email
>> with topic "Poll: Fuel PTL Elections Fall 2015".
>> >
>> > NOTE: Please, don't forward this email, it contains *personal* unique
>> token for the voting.
>> >
>> > Thanks.
>> >
>> > On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin 
>> wrote:
>> > +1 to Igor. Do we have voting system set up?
>> >
>> > On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky <
>> ikalnit...@mirantis.com> wrote:
>> > > * September 29 - October 8: PTL elections
>> >
>> > So, it's in progress. Where I can vote? I didn't receive any emails.
>> >
>> > On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala
>> >  wrote:
>> > >> On 18 Sep 2015, at 04:39, Sergey Lukjanov 
>> wrote:
>> > >>
>> > >>
>> > >> Time line:
>> > >>
>> > >> PTL elections
>> > >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
>> position
>> > >> * September 29 - October 8: PTL elections
>> > >
>> > > Just a reminder that we have a deadline for candidates today.
>> > >
>> > > Regards,
>> > > --
>> > > Tomasz 'Zen' Napierala
>> > > Product Engineering - Poland
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> __
>> > > OpenStack Development Mailing List (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
>> >
>> >
>> >
>> > --
>> > 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)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Sincerely yours,
>> > Sergey Lukjanov
>> > Sahara Technical Lead
>> > (OpenStack Data Processing)
>> > Principal Software Engineer
>> > Mirantis Inc.
>> >
>> >
>> >
>> > --
>> > Sincerely yours,
>> > Sergey Lukjanov
>> > Sahara Technical Lead
>> > (OpenStack Data Processing)
>> > Principal Software Engineer
>> > Mirantis Inc.
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > --
>> > Mike Scherbakov
>> > #mihgen
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> 

[openstack-dev] [Fuel] Testing before switching to upstream librarian

[Matthew Mosesohn]

Hi Fuelers,

It seems we have a regression on two critical bugs because of switching
Fuel to puppet-openstacklib:
https://bugs.launchpad.net/fuel/+bug/1507685

This regressed to patches that were in Fuel Library that addressed two bugs
marked as Critical.

We should improve the acceptance criteria for moving to upstream modules to
ensure no bugs are regressed that relate to the particular Puppet module
being migrated.

Secondly, what should our policy be? Revert the switch to upstream module?
Or just work on cherry-picking the appropriate fixes?

Best Regards,
Matthew Mosesohn
__
OpenStack Development Mailing List (not for 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/19/2015 12:50 PM, Fox, Kevin M wrote:
Maybe I misunderstood then. I was thinking you were proposing endpoint 
scoped tokens. But heat calls out to other endpoints itself, so if a 
token is scoped to heat, it can't relay it further.



Right...not proposing that.  This is specifically for operations on the 
Services themselves, or for operations that are not cleanly scoped to an 
existing project.  I *think* it just makes explicit what people have 
been doing implicitly.  Trying not to break things too badly.


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

[Aleksey Kasatkin]

Hi!

I mostly agree with Igor, GET request should not produce changes (i.e.
allocate VIPs).

> VIP allocation should be performed when we run deployment.

I want to give an explanation here. We have a ticket for 8.0 to give an
ability to set arbitrary addresses for VIPs. So, at least some of VIPs can
be set via API calls. And auto-allocation of addresses for VIPs should be
done just before deployment. The only concern here, whether we need a VIP
for net-checker. We could allocate VIPs on net-checker request then also
(it is PUT request).

AFAIC, we also need to provide an ability to run CheckBeforeDeployment task
separately (only within ApplyChanges for now). It will help the user to
diagnose different problems. It seems to be a subject for another
discussion/ticket though.

Thanks,




Aleksey Kasatkin


On Mon, Oct 19, 2015 at 11:28 AM, Igor Kalnitsky 
wrote:

> 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 it is possible to "spoil" network
> > configuration: when a role get’s assigned to a node, when network
> > changes or network templates are applied.
>
> It won't work that way. What if you enable plugin when all roles are
> assigned? What if you change networks, and now it's not enough IPs? Or
> what if enable plugin that requires 5 VIPs in public network by
> default, and it's not enough. But by using network templates you
> assign this netrole to management network?
>
> From what I can say the proposed approach requires to put checks
> here-and-there around the code. Let's do not overcomplicate things
> without real need.
>
> So let me share my thoughts regarding this issue.
>
> * We shouldn't *allocate* VIPs when we make GET request on network
> configuration handler. It should return only *already allocated* VIPs
> and no more.
> * VIP allocation should be performed when we run deployment.
> * Before deployment checks should fail, if there's not enough VIPs or
> other resources. So users fix them, and try again.
> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
> it's safe to return allocated VIPs on that stage.
>
> So what do you think guys?
>
> Thanks,
> Igor
>
> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko 
> wrote:
> > Hi folks!
> >
> > I’ve been discussing several bugs [1-3] with some folks and noticed that
> they share the same root cause which is that network serialization fails,
> if there’s not enough IP addresses in all available ranges of one of the
> available networks to assign them to all VIPs. There are several possible
> solutions for this issue:
> >
> > a. Not assign addresses to VIPs is a network configuration is being
> serialized for API output.
> > A lot of external tools and modules, i. e., OSTF, rely on that
> information so this relatively small change in Nailgun will require big
> cross-components changes. Therefore this change can only be done as a
> feature but it seems to be the way this issue must be fixed.
> >
> > b. Leave some VIPs without IP addresses
> > If network configuration is generated for API output it is possible to
> leave some VIPs without IP addresses assigned. This will only create more
> mess around Nailgun and bring more issues that it will resolve.
> >
> > c. Check number of IP addresses wherever it is possible to "spoil"
> network configuration: when a role get’s assigned to a node, when network
> changes or network templates are applied.
> >
> >
> > The proposal is to follow [c] as a fast solution and file a blueprint
> for [a]. Opinions?
> >
> >
> > 1 https://bugs.launchpad.net/fuel/+bug/1487996
> > 2 https://bugs.launchpad.net/fuel/+bug/1500394
> > 3 https://bugs.launchpad.net/fuel/+bug/1504572
> >
> >
> > - romcheg
> >
> >
> __
> > OpenStack Development Mailing List (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] [cinder] RemoteFS drivers refactoring: move code, which works with images to separate classes

[Dmitry Guryanov]

On 10/14/2015 12:09 AM, Sean McGinnis wrote:

On Tue, Oct 13, 2015 at 07:01:45PM +, D'Angelo, Scott wrote:

If you create a blueprint and a spec for this, the details can be discussed in 
the spec.

Yes, something like this we should definitely have a spec and blueprint
for. Please write up a spec and propose to the cinder-specs repo so this
can be discussed and comment on.


I've written the spec:
https://review.openstack.org/237094






-Original Message-
From: Dmitry Guryanov [mailto:dgurya...@virtuozzo.com]
Sent: Tuesday, October 13, 2015 12:57 PM
To: OpenStack Development Mailing List; Maxim Nestratov
Subject: [openstack-dev] [cinder] RemoteFS drivers refactoring: move code, 
which works with images to separate classes

Hello,

RemoteFS drivers combine 2 logical tasks. The first one is how to mount a 
filesystem and select proper share for a new or existing volume. The second 
one: how to deal with an image files in given directory (mount
point) (create, delete, create snapshot e.t.c.).

The first part is different for each volume driver. The second - the same for 
all volume drivers, but it depends on selected volume format:
you can create qcow2 file on NFS or smbfs with the same code.

Since there are several volume formats (raw, qcow2, vhd and possibly some 
others), I propose to move the code, which works with image to separate 
classes, 'VolumeFormat' handlers.

This change have 3 advantages:

1. Duplicated code from remotefs driver will be removed.
2. All drivers will support all volume formats.
3. New volume formats could be added easily, including non-qcow2 snapshots.

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

Aleksey,

Thank you for input.

> We have a ticket for 8.0 to give an ability to set arbitrary addresses for 
> VIPs

That shouldn't affect proposed approach. The main idea is to return
*allocated VIPs* but *do not allocate* them implicitly.

> we also need to provide an ability to run CheckBeforeDeployment task 
> separately

That's another story. Let's keep close to main subject, and a bunch of
issues mentioned by Roman,

Thanks,
Igor


On Mon, Oct 19, 2015 at 8:05 PM, Aleksey Kasatkin
 wrote:
> Hi!
>
> I mostly agree with Igor, GET request should not produce changes (i.e.
> allocate VIPs).
>
>> VIP allocation should be performed when we run deployment.
>
> I want to give an explanation here. We have a ticket for 8.0 to give an
> ability to set arbitrary addresses for VIPs. So, at least some of VIPs can
> be set via API calls. And auto-allocation of addresses for VIPs should be
> done just before deployment. The only concern here, whether we need a VIP
> for net-checker. We could allocate VIPs on net-checker request then also (it
> is PUT request).
>
> AFAIC, we also need to provide an ability to run CheckBeforeDeployment task
> separately (only within ApplyChanges for now). It will help the user to
> diagnose different problems. It seems to be a subject for another
> discussion/ticket though.
>
> Thanks,
>
>
>
>
> Aleksey Kasatkin
>
>
> On Mon, Oct 19, 2015 at 11:28 AM, Igor Kalnitsky 
> wrote:
>>
>> 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 it is possible to "spoil" network
>> > configuration: when a role get’s assigned to a node, when network
>> > changes or network templates are applied.
>>
>> It won't work that way. What if you enable plugin when all roles are
>> assigned? What if you change networks, and now it's not enough IPs? Or
>> what if enable plugin that requires 5 VIPs in public network by
>> default, and it's not enough. But by using network templates you
>> assign this netrole to management network?
>>
>> From what I can say the proposed approach requires to put checks
>> here-and-there around the code. Let's do not overcomplicate things
>> without real need.
>>
>> So let me share my thoughts regarding this issue.
>>
>> * We shouldn't *allocate* VIPs when we make GET request on network
>> configuration handler. It should return only *already allocated* VIPs
>> and no more.
>> * VIP allocation should be performed when we run deployment.
>> * Before deployment checks should fail, if there's not enough VIPs or
>> other resources. So users fix them, and try again.
>> * Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
>> it's safe to return allocated VIPs on that stage.
>>
>> So what do you think guys?
>>
>> Thanks,
>> Igor
>>
>> On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko 
>> wrote:
>> > Hi folks!
>> >
>> > I’ve been discussing several bugs [1-3] with some folks and noticed that
>> > they share the same root cause which is that network serialization fails, 
>> > if
>> > there’s not enough IP addresses in all available ranges of one of the
>> > available networks to assign them to all VIPs. There are several possible
>> > solutions for this issue:
>> >
>> > a. Not assign addresses to VIPs is a network configuration is being
>> > serialized for API output.
>> > A lot of external tools and modules, i. e., OSTF, rely on that
>> > information so this relatively small change in Nailgun will require big
>> > cross-components changes. Therefore this change can only be done as a
>> > feature but it seems to be the way this issue must be fixed.
>> >
>> > b. Leave some VIPs without IP addresses
>> > If network configuration is generated for API output it is possible to
>> > leave some VIPs without IP addresses assigned. This will only create more
>> > mess around Nailgun and bring more issues that it will resolve.
>> >
>> > c. Check number of IP addresses wherever it is possible to "spoil"
>> > network configuration: when a role get’s assigned to a node, when network
>> > changes or network templates are applied.
>> >
>> >
>> > The proposal is to follow [c] as a fast solution and file a blueprint
>> > for [a]. Opinions?
>> >
>> >
>> > 1 https://bugs.launchpad.net/fuel/+bug/1487996
>> > 2 https://bugs.launchpad.net/fuel/+bug/1500394
>> > 3 https://bugs.launchpad.net/fuel/+bug/1504572
>> >
>> >
>> > - romcheg
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 

Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

[Neil Jerram]

On 12/10/15 16:32, Sean M. Collins wrote:
> On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote:
>> ..
 In the section 
 http://docs.openstack.org/developer/devstack/guides/
>>> neutron.html#using-neutron-with-a-single-interface
 there is a helpful display of localrc contents.  It says, among other 
 things,

OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_BRIDGE=br-ex

 In the next top-level section, 
 http://docs.openstack.org/developer/devstack/guides/
>>> neutron.html#using-neutron-with-multiple-interfaces
 , there is no display of revised localrc contents and no mention of 
 changing either bridge setting.  That is an oversight, right?
>>> No, this is deliberate. Each section is meant to be independent, since
>>> each networking configuration and corresponding DevStack configuration
>>> is different. Of course, this may need to be explicitly stated in the
>>> guide, so there is always room for improvement.
>> I am not quite sure I understand your answer.  Is the intent that I can 
>> read only one section, ignore all the others, and that will tell me how to 
>> use DevStack to produce that section's configuration?  If so then it would 
>> be good if each section had a display of all the necessary localrc 
>> contents.
> Agreed. This is a failure on my part, because I was pasting in only
> parts of my localrc (since it came out of a live lab environment). I've
> started pushing patches to correct this.
>
>
>> I have started over, from exactly the picture drawn at the start of the 
>> doc.  That has produced a configuration that mostly works.  However, I 
>> tried creating a VM connected to the public network, and that failed for 
>> lack of a Neutron DHCP server there.
> The public network is used for floating IPs. The L3 agent creates NAT
> rules to intercept traffic on the public network and NAT it back to a
> guest instance that has the floating IP allocated to it.
>
> The behavior for when a guest is directly attached to the public
> network, I sort of forget what happens exactly but I do know that it
> doesn't work from experience - most likely because the network is not
> configured as a flat network. It will not receive a DHCP lease from the
> external router.
>
>> I am going to work out how to change 
>> that, and am willing to contribute an update to this doc.  Would you want 
>> that in this section --- in which case this section needs to specify that 
>> the provider DOES NOT already have DHCP service on the hardware network 
>> --- or as a new section?
> No, I think we should maybe have a warning or something that the
> external network will be used for Floating IPs, and that guest instances
> should not be directly attached to that network.

Attaching directly to an external network seems to me to be a useful
feature, and to align with the simple, flat connectivity that some
OpenStack users want.  As I wrote in a comment at
https://review.openstack.org/#/c/225384/6 (following line 102 of the
proposed spec):

  "The way I see this now, the Neutron API gives operators and tenants a
rather awesome choice. Operators can pre-configure external networks,
and provide reachability between those, and to the outside world, using
their data center fabric or however, in a way that is not explicitly
described on the Neutron API. Then tenants can choose either to attach
directly to those external networks, or to create their own more private
networks, and specify explicitly whether and how those route to the
external networks."

My point wasn't accepted in every detail - please see the following
comments for details - but I currently still think that it's broadly
correct, and hence that attaching to external networks is a Neutron feature.

Neil


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

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

[Mike Scherbakov]

This is great start, Evgeny.
I have a few questions:

   1. When do you expect to have POC to show?
   2. Do you plan to put new services into separate repos?
   3. 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 (currently it's too Fuel and Cobbler
> specific)
> >
> > Network configuration
> > * CRUD api on any entity in the system (in Fuel not all of the data are
> > exposed via api,
> >   so user has to go and edit entries in db manually)
> > * no constraints regarding to network topology (in Fuel there are a lot
> of
> > hardcoded
> >   assumptions)
> >
> > Node hardware discovery
> > * should be able to support different source drivers at the same time
> >(csv file, fuel-nailgun-agent, CMDB, dhcp, cobbler etc)
> > * versioning of HW information (required for life cycle management)
> > * notification about changes in hardware or about node statuses
> >   (required for life cycle management)
> >
> > Common requirements for components:
> > * every component must follow OpenStack coding standards when
> >   we start working upstream after POC (so there shouldn't be a question
> >   what to use pecan of flask)
> > * Fuel specific interfaces should be implemented as drivers
> > * this one is obvious, but currently one of the most problematic parts in
> > Fuel,
> >   HW gets changed, interface can be replaced, disk can be removed,
> >   component should have a way to handle it
> >
> > Technically speaking, we want to have separate services for every
> component,
> > it is one of the technical ways to force components to have clear
> > interfaces.
> >
> > Other architecture decision which we want to try to solve is
> extendability,
> > currently we have a problem that all of the logic which is related to
> > deployment
> > data is hardcoded in Nailgun. Plugins should be able to retrieve any
> data it
> > needs from the system, in order to perform plugin deployment, these data
> > should
> > be retrieved using some interface, and we already have interface where we
> > can
> > provide stability and versioning, it's REST API. So basically deployment
> > should
> > consist of two steps first is to retrieve all required data from any
> source
> > it needs,
> > and after 

Re: [openstack-dev] [ironic] [neutron] Enforce port/portgroup MAC uniqueness constraint

[Kevin Benton]

In Neutron they are forced to be unique within a network.[1]

Are you asking if they can be required to be globally unique in Neutron?

1.
https://github.com/openstack/neutron/blob/1f7d246f467607e0b065848b324d1ed6b3b47614/neutron/db/models_v2.py#L134-L136

On Mon, Oct 19, 2015 at 4:38 PM, William Stevenson 
wrote:

> Hi,
>
> In reference to comments on a patchset[1], port/portgroup addresses
> should be unique. Please also see the irc log[1] which includes
> earlier discussion regarding rationale.
>
> Q: How can we enforce this uniqueness across tables?
>
>
> [1]
> https://review.openstack.org/#/c/206232/26/ironic/db/sqlalchemy/alembic/versions/5ea1b0d310e_added_port_group_table_and_altered_ports.py
> [2] http://ix.io/luF/irc
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [nova] Nova's Mitaka Release Schedule

[John Garbutt]

Hi,

I have put together a list of proposed Nova specific deadlines:
https://wiki.openstack.org/wiki/Nova/Mitaka_Release_Schedule

We can go through what needs to change in that list during the summit,
and in the nova IRC meeting following the summit.

Thanks,
johnthetubaguy

PS
Please note I have moved the process FAQs to:
https://wiki.openstack.org/wiki/Nova/Process
Help to move those into the project guide, would be very welcome.

__
OpenStack Development Mailing List (not for 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/19/2015 12:39 PM, Neil Jerram wrote:

On 19/10/15 14:57, Adam Young wrote:

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.

I'm afraid I'm not sure I follow.  Do you mean all of the admin
operations on resources that are protected only by 'role==admin' ?

Yes, exactly. For example, Nova has such a call with "Hypervisors"

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json#n159

An there is no clear project that this call can be scoped to.

Contrast this with update-quota which should be scoped to a project.

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json#n175




 Neil


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



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

[Fox, Kevin M]

Maybe I misunderstood then. I was thinking you were proposing endpoint scoped 
tokens. But heat calls out to other endpoints itself, so if a token is scoped 
to heat, it can't relay it further.

Thanks,
Kevin

From: Adam Young [ayo...@redhat.com]
Sent: Monday, October 19, 2015 9:00 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cross-project] Admin

On 10/19/2015 11:53 AM, Fox, Kevin M wrote:

+1.

I think there may be a slight issue with this and Heat, or any other service 
depending on Heat though. It would have to be very carefully through through, 
since Heat acts on behalf of the user as the User him/herself would, so scoping 
may need to interact differently there, then say Nova. Maybe a flag in the 
service catalog saying if the service can be scoped or not?

I think there is a subtlety there you are not making clear.  Why would Heat, or 
any other service not be scoped?  The only rule I am seeing in Heat's policy 
would be

"service:index": "rule:context_is_admin",

 http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/policy.json


But that certainly suffers from the admin-ess problem.  There is certainly 
something strange with the deny rules;  it is trivial to bypass this role with 
a trust.  Somethin needs a second look there anyway.



Thanks,
Kevin

From: Adam Young [ayo...@redhat.com]
Sent: Monday, October 19, 2015 6:53 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [cross-project] Admin

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.

We have a few choices.

1.  Remove Admin from the scoping for projects. Admin is a special role
reserved only for system admins.  Replace project scoped admins with
'manager' or some other comparable role.  This is actually the easiest
solution.

2.  Create a special project for administrative actions.  Cloud admin
users are assigned to this project. Communicate that project Id to the
remote systems.  This is what the policy.v3cloudsample.json file
(http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
recommends.

However, 2 is really not practical without some significant
engineering.  For a new deployment, it would require the following steps.
1) Every single policy file would have to be "templatized"
2) Then deployment mechanism would have to create the admin project, get
the id for it, and string replace it in the policy file.

We could make this happen in Devstack.  The same is true of Puppet,
OSAD, and Fuel.  There would be a lag and the downstream mechanisms
would eventually pick it up, multiple releases down the road.
I went through this logic back when I started proposing the Dynamic
Policy approach.  If OpenStack managed policy deployment via an
inte4rnal mechanism, then adding things like the admin_project_id
becomes trivial.


While I think Dynamic Policy provides a lot of value, I concede that it
is overkill for just substituting in a single value.  The real reason I
am backing off Dynamic Policy for the moment is that we need to better
understand what part of policy should be dynamic and what part should be
static;  we are just getting that clean now.


There is an additional dimension to the admin_project_id issue that
several developers want solved.  In larger deployments, different users
should have administrative capabilities on different endpoints.
Sometimes this is segregated by service (storage admins vs network
admins) and sometimes by region.

Having a special project clearly communicates the intention of RBAC.
But even clearer would be to have the role assignment explicitly on the
catalog item itself.  Which of the following statements would you think
is clearer?


1) Assign Joe the admin role on the project designated to administer
endpoint 0816.
2) 1) Assign Joe the admin role on endpoint 0816.

I think you will agree that it is the latter.  Making this happen would
not be too difficult on the Keystone side, and would require fairly
simple changes on the policy enforcement of the remote projects.  

Re: [openstack-dev] [cinder] Rolling upgrades - missing pieces

[Sean McGinnis]

On Mon, Oct 19, 2015 at 03:10:16PM +, Dulko, Michal wrote:
> Hi all,
> 
> One of our priority goals for Liberty was the adoption of
> oslo.versionedobjects in order for Cinder to achieve ability to do
> rolling upgrades. We weren't successful with that in L, and work got
> postponed to Mitaka. I want to highlight remaining work in that topic as
> well as other pieces that are still missing in order for Cinder to
> support no-downtime-upgrades.
> 

> 
> Changing this is required for us to be able to remove or rename fields
> in these dictionaries and still be able to provide interoperability of
> services working in different versions.
> 
> I would love to get some feedback on these thoughts and possibly start a
> pre-summit discussion on the whole topic.

Thanks for bringing this up Michal. Will you be around for the weekly
meeting this week? It would be great if we could get this on the agenda
just to make sure everyone is aware of it. 

That may help to make sure more folks have had a chance to think about
this, even briefly, before the design summit.

Thanks!
Sean

> 
> [1] http://www.danplanet.com/blog/2015/10/05/upgrades-in-nova-rpc-apis/
> [2] http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/
> [3] 
> http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/
> [4] 
> https://github.com/openstack/nova/blob/master/nova/tests/unit/db/test_migrations.py#L186-L227
> [5] 
> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/online-schema-changes.html
> [6] 
> https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:bp/cinder-objects,n,z
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for 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 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 it is possible to "spoil" network
> configuration: when a role get’s assigned to a node, when network
> changes or network templates are applied.

It won't work that way. What if you enable plugin when all roles are
assigned? What if you change networks, and now it's not enough IPs? Or
what if enable plugin that requires 5 VIPs in public network by
default, and it's not enough. But by using network templates you
assign this netrole to management network?

From what I can say the proposed approach requires to put checks
here-and-there around the code. Let's do not overcomplicate things
without real need.

So let me share my thoughts regarding this issue.

* We shouldn't *allocate* VIPs when we make GET request on network
configuration handler. It should return only *already allocated* VIPs
and no more.
* VIP allocation should be performed when we run deployment.
* Before deployment checks should fail, if there's not enough VIPs or
other resources. So users fix them, and try again.
* Both Fuel UI and OSTF needs VIPs only when cluster is deployed, and
it's safe to return allocated VIPs on that stage.

So what do you think guys?

Thanks,
Igor

On Fri, Oct 16, 2015 at 5:25 PM, Roman Prykhodchenko  wrote:
> Hi folks!
>
> I’ve been discussing several bugs [1-3] with some folks and noticed that they 
> share the same root cause which is that network serialization fails, if 
> there’s not enough IP addresses in all available ranges of one of the 
> available networks to assign them to all VIPs. There are several possible 
> solutions for this issue:
>
> a. Not assign addresses to VIPs is a network configuration is being 
> serialized for API output.
> A lot of external tools and modules, i. e., OSTF, rely on that information so 
> this relatively small change in Nailgun will require big cross-components 
> changes. Therefore this change can only be done as a feature but it seems to 
> be the way this issue must be fixed.
>
> b. Leave some VIPs without IP addresses
> If network configuration is generated for API output it is possible to leave 
> some VIPs without IP addresses assigned. This will only create more mess 
> around Nailgun and bring more issues that it will resolve.
>
> c. Check number of IP addresses wherever it is possible to "spoil" network 
> configuration: when a role get’s assigned to a node, when network changes or 
> network templates are applied.
>
>
> The proposal is to follow [c] as a fast solution and file a blueprint for 
> [a]. Opinions?
>
>
> 1 https://bugs.launchpad.net/fuel/+bug/1487996
> 2 https://bugs.launchpad.net/fuel/+bug/1500394
> 3 https://bugs.launchpad.net/fuel/+bug/1504572
>
>
> - romcheg
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[George Silvis, III]

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.

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





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

[openstack-dev] [nova] Checking dates for the Mitaka Nova Midcycle

[John Garbutt]

Hi,

We have a few offers for midcycle dates.

If you would like to attend, please let me know if:
* the proposed date works for you
* one of the proposed venues is a no go (budget or otherwise)

http://doodle.com/poll/88sbzgcv28rww2n3

Thanks,
johnthetubaguy

PS
If doodle doesn't work for you, let me know and I can add your vote in.

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