[Openstack] work from home 19.10.2015

[Ivan Derbenev]

Ввиду проведения санехнических работы вынужден поработать из дома первую 
половину дня

Regards,
IT engineer
Farheap, Russia
Ivan Derbenev

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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] OpenStack "Liberty" is officially released !

[Neil Jerram]

Is there any ETA for permanent RDO Liberty packages?

Thanks,
  Neil


From: Matt Kassawara [mailto:mkassaw...@gmail.com]
Sent: 16 October 2015 20:04
To: Martinx - ジェームズ 
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] OpenStack "Liberty" is officially released !

Ubuntu has not published Liberty release packages to the cloud archive 
repository (for 14.04) and RDO has not provided a permanent location for any 
Liberty packages yet.

On Fri, Oct 16, 2015 at 12:04 PM, Martinx - ジェームズ 
> wrote:
Amazing times!!! Thanks you guys!

It is already included in Ubuntu 15.10 and for Ubuntu 14.04 via Ubuntu
Cloud Archive... Perfect! Super easy to upgrade...

Congratulations!

On 15 October 2015 at 13:43, Thierry Carrez 
> wrote:
> Hello everyone,
>
> I'm very pleased to announce the final releases of OpenStack Liberty,
> which conclude the 6-month Liberty development cycle.
>
> This is the first of our "Big Tent" releases, which means that we have a
> lot more components around. You can find the complete list of
> already-released Liberty versions at:
>
> http://docs.openstack.org/releases/releases/liberty.html
>
> The Liberty Release Notes wikipage contains an overview of the key
> features, as well as upgrade notes and current lists of known issues.
> You can access them at:
>
> https://wiki.openstack.org/wiki/ReleaseNotes/Liberty
>
> The OpenStack release management team directly handled a number of
> services. You can find their source tarballs, together with complete
> lists of features and bugfixes for each project, at the following links:
>
> nova:   https://launchpad.net/nova/liberty/12.0.0
> swift:  https://launchpad.net/swift/liberty/2.5.0
> glance: https://launchpad.net/glance/liberty/11.0.0
> neutron:https://launchpad.net/neutron/liberty/7.0.0
> cinder: https://launchpad.net/cinder/liberty/7.0.0
> keystone:   https://launchpad.net/keystone/liberty/8.0.0
> horizon:https://launchpad.net/horizon/liberty/8.0.0
> ceilometer: https://launchpad.net/ceilometer/liberty/5.0.0
> heat:   https://launchpad.net/heat/liberty/5.0.0
> trove:  https://launchpad.net/trove/liberty/4.0.0
> sahara: https://launchpad.net/sahara/liberty/3.0.0
> ironic: https://launchpad.net/ironic/liberty/4.2.0
> designate:  https://launchpad.net/designate/liberty/1.0.0
> zaqar:  https://launchpad.net/zaqar/liberty/1.0.0
> manila: https://launchpad.net/manila/liberty/1.0.0
> barbican:   https://launchpad.net/barbican/liberty/1.0.0
>
> Thanks again to all the individuals who contributed to this development
> cycle and helped in making this release a success !
>
> Our next development cycle, Mitaka, is already started. We'll all gather
> in Tokyo in 10 days at the Mitaka Design Summit to brainstorm and plan
> this next cycle.
>
> See you there !
>
> --
> Thierry Carrez (ttx)
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : 
> openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Openstack Kilo Vxlan tunnel single NIC setup

[Akash Gunjal]

Hi Amir,

One point to check is the security rules set in your controller. Check if
you have set the ingress/egress rules set for ICMP protocol (ping) which
will otherwise block traffic from external hosts to the tenant VM.

Regards,
Akash



From:   yatin kumbhare 
To: Amir Huskić 
Cc: "openstack@lists.openstack.org" 
Date:   10/19/2015 03:56 PM
Subject:Re: [Openstack] Openstack Kilo Vxlan tunnel single NIC setup



Hi Amir,

Not quite sure, as I haven't tried such a thing.

but IMHO, you might require l2-gateway.

Kind of this: https://www.youtube.com/watch?v=74Wfr4myf5k

Regards,
Yatin

On Mon, Oct 19, 2015 at 4:35 AM, Amir Huskić  wrote:
  Hello James,

  I use underscores in ml2 config file as You suggested. Also made some
  changes in config file. Here is available:
  https://www.dropbox.com/s/fuzwiyuyfngyyl2/ml2_conf.ini?dl=0

  Summary:
  - can ping from OS host to external gw and external linux host
  - can ping from tenant VM to external gw and external linux host
  - can't ping OS host and tenant VM floating IP from external linux host
  - tcpdump on br-ex and eth0 interface is showing arp request during ping
  request from linux external host using vxlan segment

  For additional info please check info from CLI screen here:
  https://www.dropbox.com/s/fv5hen4jbo6fmby/CLI_debug.txt?dl=0

  Accidently I deleted symbolic link in log files pointing to agent log.
  Unfortunately I don't know how to create it again with proper
  permissions. I tried with chmod and chown using reference command but
  without much success.

  lrwxrwxrwx  1 amir amir    43 Sep 19 15:26 screen-n-sch.log ->
  /opt/stack/logs/n-sch.log.2015-09-19-150746
  -rw-r--r--  1 amir amir 245730291 Okt 18 14:00 screen-q-agt.log
  lrwxrwxrwx  1 amir amir    44 Sep 19 15:25 screen-q-dhcp.log ->
  /opt/stack/logs/q-dhcp.log.2015-09-19-150746


  Thank you for your help and time.

  Kind regards,
  Amir
  
  
  


  On Wed, Oct 14, 2015 at 4:06 PM, James Denton  wrote:
   Hi Amir,

   A couple of recommendations:

   - Your vxlan_group setting has an extra dot at the end that may be
   causing issues:
   [ml2_type_vxlan]
   vxlan_group = 239.0.0.0.
   - Your [OVS] block has some incorrect options. Use underscores rather
   than spaces:
   [ovs]
   bridge_mappings = public:br-ex
   local_ip = 192.168.100.100
   vxlan_udp_port = 8472
   tunnel type = vxlan
   tunnel id ranges = 1001:2000
   tenant network type = vxlan
   enable tunneling = true
   - Same goes for [agent] as well:
   [agent]
   tunnel_types = vxlan
   root_helper_daemon =
   sudo /usr/local/bin/neutron-rootwrap-daemon /etc/neutron/rootwrap.conf
   root_helper =
   sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
   #tunnel_types = vxlan
   vxlan_udp_port = 8472
   l2 population = false
   Start by correcting those issues and restart the OVS agents across your
   hosts. The agent log may be of help here as well.

   James

 On Oct 14, 2015, at 2:38 AM, Amir Huskić 
 wrote:

 Hello,

 there is also my ml2_conf.ini file:
 https://dl.dropboxusercontent.com/u/4298410/ml2_conf.ini

 Could problem be related to single NIC installation? Is it
 possible to have same interface for bridge mappings and also for
 tunnel bridge? Example below:

 bridge_mappings = public:br-ex
 integration bridge = br-int
 tunnel bridge = br-ex

 Thank you.
 Regards,
 Amir


 On Mon, Oct 12, 2015 at 3:53 PM, Amir Huskić <
 amir.hus...@gmail.com> wrote:
   Hi all,

   I'm trying to setup up Openstack test lab.

   I deployed Openstack Kilo (Devstack) on PC running Ubuntu LTS
   14.02 with single NIC.
   Tenants are isolated with vxlan networks. I can ping from VMs to
   external network PCs, SSH login from external PCs to tenants VMs
   floating IP address, etc.

   I would like also to connect tenant VMs to external network
   physical Linux host using vxlan tunnel and have L2 connectivity
   between VM and physical Linux host over L3 network.

   Vxlan interface on Linux physical host is up and running. When I
   am trying to ping from Linux physical host to Openstack VM (not
   floating IP) using same subnet L2 address (example ping from
   192.168.10.10 to 192.168.10.11) UDP packets on port 8472 are
   coming to Openstack br-ex interface with ARP request.

   Problem is that I can't setup vxlan tunnel on Openstack.
   Command "sudo ovs-vsctl show" doesn't show any vxlan tunnels.
   Also when I try to ping from VM to Linux host using L2 IP
   address (ping from 192.168.10.11 to 192.168.10.10) tcpdump on
   br-ex doesn't show 

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

[Openstack-operators] Tokyo Ops Design Summit Track - Last minute updates

[Tom Fifield]

Hi everyone,

Some last minute updates for the Tokyo Ops Design Summit Track

* We are still lacking a moderator for "Quotas and Billing"
==> This session will be cancelled if noone can be found.

* Information
==> Sched: https://mitakadesignsummit.sched.org/overview/type/ops
==> Etherpads: https://etherpad.openstack.org/p/TYO-ops-meetup
==> Maps: https://www.openstack.org/summit/tokyo-2015/campus-maps/

* We need your help to promote the track.
==> Please do whatever you can to get ops folk there.


Regards,


Tom

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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 

[OpenStack-Infra] Request to add group member into the new

[Mateusz Matuszkowiak]

Hi openstack-infra team,

Kindly please add > to the following Gerrit ACL groups:
-
https://review.openstack.org/#/admin/groups/1116,members 

https://review.openstack.org/#/admin/groups/1117,members 

(ref. https://review.openstack.org/#/c/229801/ 
)

Thanks in advance.

Kind Regards
--
Fuel DevOps
Mateusz Matuszkowiak




___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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] Openstack Kilo Vxlan tunnel single NIC setup

[yatin kumbhare]

Hi Amir,

Not quite sure, as I haven't tried such a thing.

but IMHO, you might require l2-gateway.

Kind of this: https://www.youtube.com/watch?v=74Wfr4myf5k

Regards,
Yatin

On Mon, Oct 19, 2015 at 4:35 AM, Amir Huskić  wrote:

> Hello James,
>
> I use underscores in ml2 config file as You suggested. Also made some
> changes in config file. Here is available:
> https://www.dropbox.com/s/fuzwiyuyfngyyl2/ml2_conf.ini?dl=0
>
> Summary:
> - can ping from OS host to external gw and external linux host
> - can ping from tenant VM to external gw and external linux host
> - can't ping OS host and tenant VM floating IP from external linux host
> - tcpdump on br-ex and eth0 interface is showing arp request during ping
> request from linux external host using vxlan segment
>
> For additional info please check info from CLI screen here:
> https://www.dropbox.com/s/fv5hen4jbo6fmby/CLI_debug.txt?dl=0
>
> Accidently I deleted symbolic link in log files pointing to agent log.
> Unfortunately I don't know how to create it again with proper permissions.
> I tried with chmod and chown using reference command but without much
> success.
>
> lrwxrwxrwx  1 amir amir43 Sep 19 15:26 screen-n-sch.log ->
> /opt/stack/logs/n-sch.log.2015-09-19-150746
> *-rw-r--r--  1 amir amir 245730291 Okt 18 14:00 screen-q-agt.log*
> lrwxrwxrwx  1 amir amir44 Sep 19 15:25 screen-q-dhcp.log ->
> /opt/stack/logs/q-dhcp.log.2015-09-19-150746
>
>
> Thank you for your help and time.
>
> Kind regards,
> Amir
>
>
> On Wed, Oct 14, 2015 at 4:06 PM, James Denton 
> wrote:
>
>> Hi Amir,
>>
>> A couple of recommendations:
>>
>> - Your vxlan_group setting has an extra dot at the end that may be
>> causing issues:
>>
>> [ml2_type_vxlan]
>>
>> vxlan_group = 239.0.0.0.
>>
>> - Your [OVS] block has some incorrect options. Use underscores rather
>> than spaces:
>>
>> [ovs]
>> bridge_mappings = public:br-ex
>> local_ip = 192.168.100.100
>> vxlan_udp_port = 8472
>> tunnel type = vxlan
>> tunnel id ranges = 1001:2000
>> tenant network type = vxlan
>> enable tunneling = true
>>
>> - Same goes for [agent] as well:
>>
>> [agent]
>> tunnel_types = vxlan
>> root_helper_daemon = sudo /usr/local/bin/neutron-rootwrap-daemon 
>> /etc/neutron/rootwrap.conf
>> root_helper = sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
>> #tunnel_types = vxlan
>> vxlan_udp_port = 8472
>> l2 population = false
>>
>> Start by correcting those issues and restart the OVS agents across your
>> hosts. The agent log may be of help here as well.
>>
>> James
>>
>> On Oct 14, 2015, at 2:38 AM, Amir Huskić  wrote:
>>
>> Hello,
>>
>> there is also my ml2_conf.ini file:
>> https://dl.dropboxusercontent.com/u/4298410/ml2_conf.ini
>>
>> Could problem be related to single NIC installation? Is it possible to
>> have same interface for bridge mappings and also for tunnel bridge? Example
>> below:
>>
>> bridge_mappings = public:br-ex
>> integration bridge = br-int
>> tunnel bridge = br-ex
>>
>> Thank you.
>> Regards,
>> Amir
>>
>>
>> On Mon, Oct 12, 2015 at 3:53 PM, Amir Huskić 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to setup up Openstack test lab.
>>>
>>> I deployed Openstack Kilo (Devstack) on PC running Ubuntu LTS 14.02 with
>>> single NIC.
>>> Tenants are isolated with vxlan networks. I can ping from VMs to
>>> external network PCs, SSH login from external PCs to tenants VMs floating
>>> IP address, etc.
>>>
>>> I would like also to connect tenant VMs to external network physical
>>> Linux host using vxlan tunnel and have L2 connectivity between VM and
>>> physical Linux host over L3 network.
>>>
>>> Vxlan interface on Linux physical host is up and running. When I am
>>> trying to ping from Linux physical host to Openstack VM (not floating IP)
>>> using same subnet L2 address (example ping from 192.168.10.10 to
>>> 192.168.10.11) UDP packets on port 8472 are coming to Openstack br-ex
>>> interface with ARP request.
>>>
>>> Problem is that I can't setup vxlan tunnel on Openstack.
>>> Command "sudo ovs-vsctl show" doesn't show any vxlan tunnels.
>>> Also when I try to ping from VM to Linux host using L2 IP address (ping
>>> from 192.168.10.11 to 192.168.10.10) tcpdump on br-ex doesn't show anything.
>>>
>>> My ml2_conf.ini files is configured following this guide:
>>> http://www.opencloudblog.com/?p=300
>>>
>>> Thanks in advance for your help,
>>>
>>> Regards,
>>> Amir
>>>
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> 

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] work from home 19.10.2015

[Marton Kiss]

Have a good luck for the home office!

M.

On Mon, Oct 19, 2015 at 9:15 AM Ivan Derbenev 
wrote:

> Ввиду проведения санехнических работы вынужден поработать из дома первую
> половину дня
>
>
>
> Regards,
>
> IT engineer
>
> Farheap, Russia
>
> Ivan Derbenev
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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

Re: [Openstack] Convert from GRE to VLAN

[James Denton]

Hi Florian,

It is possible, though maybe not for the faint of heart depending on your 
strategy. You can:

1. Create new VLAN networks using the same subnet CIDRs as the existing GRE 
networks, then detach existing interfaces and attach new interfaces with the 
same IPs. You would need to detach/attach router interfaces as well and maybe 
change floating IP associations. There are quite a few steps here but it is 
possible.

2. Make the changes to the database and restart services. This is not the route 
I would go if I could avoid it, but it has been done. We went from OVS/GRE to 
ML2/LinuxBridge/VLAN over a year ago in some live environments. I highly 
recommend simulating this in a lab environment before doing it live.

Here’s some links on the latter that talk about what we did:

https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/migrating-production-workloads-from-ovs-to-linux-bridge-w-ml2
 


https://github.com/busterswt/openstackparis2014 


James

> On Oct 18, 2015, at 3:15 AM, Florian Rommel  
> wrote:
> 
> Hi, I have a problem that I need to convert our Dev environment to VLAN from 
> GRE tunnels.
> Can someone assist me on how complicated it is? the environment is about 10 
> nodes including compute, storage and control nodes.
> 
> There can be a LITTLE bit of downtime but not that much (hour, maybe 2?)
> Is this even possible?
> 
> 
> Thanks for any help, you can also contact me directly.
> 
> Best regards,
> //Florian
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[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-operators] [ceilometer] ceilometer+ops feedback

[gord chung]

hi folks,

just an fyi, the Ceilometer+Aodh+Gnocchi development teams will be using 
the contributor meetup time[1] to review the feedback provided from the 
various surveys[2] passed around recently. similar to last summit, 
you're all welcome to pop in and provide any issues you'd like to have 
address/raised.


[1] 
https://mitakadesignsummit.sched.org/event/33dd2b2224898ff8fd5c5d8c3fa9f08b

[2] https://goo.gl/rKNhM1

cheers,

--
gord


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] [neutron] one SDN controller and many OpenStack environments

[Dileep Varma Bairraju]

Hi Piotr,

Floodlight supports multiple openstack controllers upstream at the same
time. Floodlight keeps tracks of active endpoints, it will check if a MAC
exists during learning phase preventing second end point coming up if it
has the same MAC.

my 2 cents.

Regards,
Dileep



On Wed, Oct 14, 2015 at 3:01 AM, Piotr Misiak 
wrote:

> Hi,
>
> Do you know if there is a possibility to manage tenants networks in many
> OpenStack environments by one SDN controller (via Neutron plugin)?
>
> Suppose I have in one DC two or three OpenStack env's (deployed for
> example by Fuel) and I have a SDN controller which manages all switches
> in DC. Can I connect all those OpenStack env's to the SDN controller
> using plugin for Neutron? I'm curious what will happen if there will be
> for example the same MAC address in two OpenStack env's?
> Maybe I should not connect those OpenStack env's to the SDN controller
> and use a standard OVS configuration?
>
> Which SDN controller would you recommend? I'm researching these currently:
> - OpenDaylight
> - Floodlight
> - Ryu
>
> Thanks,
> Piotr Misiak
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>



-- 
Regards,
Dileep V Bairraju
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[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] [Liberty] What happened with "glance image-create --location http://..." ?

[Martinx - ジェームズ]

Hey guys,

The recommended workaround worked! On Liberty, I'm using it like this now:

---
glance --os-image-api-version 1 image-create --location
http://uec-images.ubuntu.com/releases/14.04.3/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img
--is-public true --disk-format qcow2 --container-format bare --name
"Ubuntu 14.04.3 LTS - Trusty Tahr - 64-bit - Cloud Based Image"

glance --os-image-api-version 1 image-update --property
hw_scsi_model=virtio-scsi --property hw_disk_bus=scsi "Ubuntu 14.04.3
LTS - Trusty Tahr - 64-bit - Cloud Based Image"
---

Nevertheless, how can we achieve the same results, but using new OS
Image API version 2?

I mean, with "--location" from API 1, we can add lots of images in
advance and then, Glance will only download those images, on demand
(i.e., on first launch). So, how to do the same but, using API 2? This
is a very important feature...

Also, it seems that "image-update" is different on v2 as well...

Thanks!
Thiago


On 19 October 2015 at 01:06, Morales, Victor  wrote:
> Agree, it has been implemented that argument for V2(new default version)
> for python glance client
> (https://github.com/openstack/python-glanceclient/blob/master/glanceclient/
> v2/shell.py#L46-L59). A workaround could be use the OS_IMAGE_API_VERSION=1
> to use the --location argument of the
> client(https://github.com/openstack/python-glanceclient/blob/master/glancec
> lient/v1/shell.py#L195-L200)
>
> Regards/Saludos
> Victor Morales
>
> On 10/18/15, 6:31 PM, "James Denton"  wrote:
>
>>Hi Thiago,
>>
>>I'm not sure, but this may be a change from v1 API to v2 API. Here's a
>>bug I found a few months ago that may be related:
>>
>>https://bugs.launchpad.net/python-glanceclient/+bug/1399778
>>
>>James
>>
>>From: Martinx - ジェームズ 
>>Sent: Sunday, October 18, 2015 2:28 AM
>>To: openstack@lists.openstack.org
>>Subject: [Openstack] [Liberty] What happened with "glance image-create
>>--location http://...; ?
>>
>>Hey guys,
>>
>>I'm trying Liberty (on Trusty) for the first time now... I'm facing
>>one problem that I think it might be easy to obtain help...
>>
>>To begin with:
>>
>>source admin-openrc.sh
>>glance image-list
>>
>>...works...
>>
>>But, I'm trying to add an image to it and it fails, like this:
>>
>>---
>>myuser@liberty-1:~$ glance image-create --location
>>http://uec-images.ubuntu.com/releases/14.04.3/release/ubuntu-14.04-server-
>>cloudimg-amd64-disk1.img
>>--visibility public --disk-format qcow2 --container-format bare --name
>>"Ubuntu 14.04.3 LTS - Trusty Tahr - 64-bit - Cloud Based Image"
>>usage: glance [--version] [-d] [-v] [--get-schema] [--timeout TIMEOUT]
>>  [--no-ssl-compression] [-f] [--os-image-url OS_IMAGE_URL]
>>  [--os-image-api-version OS_IMAGE_API_VERSION]
>>  [--profile HMAC_KEY] [-k] [--os-cert OS_CERT]
>>  [--cert-file OS_CERT] [--os-key OS_KEY] [--key-file OS_KEY]
>>  [--os-cacert ] [--ca-file OS_CACERT]
>>  [--os-username OS_USERNAME] [--os-user-id OS_USER_ID]
>>  [--os-user-domain-id OS_USER_DOMAIN_ID]
>>  [--os-user-domain-name OS_USER_DOMAIN_NAME]
>>  [--os-project-id OS_PROJECT_ID]
>>  [--os-project-name OS_PROJECT_NAME]
>>  [--os-project-domain-id OS_PROJECT_DOMAIN_ID]
>>  [--os-project-domain-name OS_PROJECT_DOMAIN_NAME]
>>  [--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID]
>>  [--os-tenant-name OS_TENANT_NAME] [--os-auth-url
>>OS_AUTH_URL]
>>  [--os-region-name OS_REGION_NAME]
>>  [--os-auth-token OS_AUTH_TOKEN]
>>  [--os-service-type OS_SERVICE_TYPE]
>>  [--os-endpoint-type OS_ENDPOINT_TYPE]
>>   ...
>>glance: error: unrecognized arguments: --location
>>http://uec-images.ubuntu.com/releases/14.04.3/release/ubuntu-14.04-server-
>>cloudimg-amd64-disk1.img
>>---
>>
>>What happens to "--location" option?
>>
>>I'm using a very similar line to add images to Kilo, only difference
>>is that on Kilo, I'm using "--is-public true", instead of
>>"--visibility public" (Liberty)...
>>
>>If I download the file, and use "--file", instead of "--location" as
>>before, then it works... But I prefer to add download the images on
>>demand...
>>
>>Workaround:
>>
>>---
>>wget
>>http://uec-images.ubuntu.com/releases/14.04.3/release/ubuntu-14.04-server-
>>cloudimg-amd64-disk1.img
>>
>>glance image-create --file
>>ubuntu-14.04-server-cloudimg-amd64-disk1.img --disk-format qcow2
>>--container-format bare --name "Ubuntu 14.04.3 LTS - Trusty Tahr -
>>64-bit - Cloud Based Image"
>>+--+--
>>-+
>>| Property | Value
>>|
>>+--+--
>>-+
>>| checksum | 

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-Infra] Request to add group member into the new

[Spencer Krum]

I've added you to the correct groups.

Thanks,
Spencer

On Mon, Oct 19, 2015 at 3:13 AM, Mateusz Matuszkowiak <
mmatuszkow...@mirantis.com> wrote:

> Hi openstack-infra team,
>
> Kindly please add  to the following Gerrit
> ACL groups:
> -
> https://review.openstack.org/#/admin/groups/1116,members
> https://review.openstack.org/#/admin/groups/1117,members
> (ref. https://review.openstack.org/#/c/229801/)
>
> Thanks in advance.
>
> Kind Regards
> --
> Fuel DevOps
> Mateusz Matuszkowiak
>
>
>
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>


-- 
Spencer Krum
(619)-980-7820
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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] Unable to launch hadoop cluster in Sahara

[varun bhatnagar]

Hi,

Got a bit further with 4.0.2mrv2 image, I saw some commands getting
executed:

2015-10-19 16:47:55.573 1434 DEBUG sahara.utils.ssh_remote [-]
[launchnew-test402-001] Executing "apt-get install --force-yes -y
mapr-jobtracker mapr-tasktracker" _log_command
/usr/lib/python2.7/site-packages/sahara/utils/ssh_remote.py:767

2015-10-19 16:48:32.451 1434 DEBUG sahara.utils.ssh_remote [-]
[launchnew-test402-001] _execute_command took 36.9 seconds to complete
_log_command /usr/lib/python2.7/site-packages/sahara/utils/ssh_remote.py:767
2015-10-19 16:48:33.733 1434 DEBUG sahara.utils.ssh_remote [-]
[launchnew-test402-001] Executing "apt-get install --force-yes -y
mapr-zookeeper mapr-webserver" _log_command
/usr/lib/python2.7/site-packages/sahara/utils/ssh_remote.py:767

2015-10-19 16:49:30.532 1434 DEBUG sahara.utils.ssh_remote [-]
[launchnew-test402-001] Executing "apt-get install --force-yes -y
mapr-oozie-internal=4.0.1* mapr-oozie=4.0.1*" _log_command
/usr/lib/python2.7/site-packages/sahara/utils/ssh_remote.py:767


But after sometime met with a new error:

2015-10-19 17:20:18.310 1434 ERROR sahara.service.ops [-] Error during
operating on cluster launchNEW (reason: An error occurred in thread
'configure-sh-dba1f3ab-5dbb-4752-b1a4-ece3c8c97f02': 'Operation' timed out
after 600 second(s)
Error ID: dd43c7da-cf29-4264-9563-4bc199bba1dc
Error ID: ba104047-f1f0-460e-bb18-1cf8eac6f865)
2015-10-19 17:20:18.677 1434 INFO sahara.utils.general [-] Cluster status
has been changed: id=c8ece084-20f5-4905-b01f-95679cbdb4fc, New status=Error


After logging into the node I can see that the packages got installed

mapr-core-internal is already the newest version.
mapr-core-internal set to manually installed.
mapr-fileserver is already the newest version.
mapr-hadoop-core is already the newest version.
mapr-hadoop-core set to manually installed.
mapr-jobtracker is already the newest version.
mapr-mapreduce1 is already the newest version.
mapr-mapreduce1 set to manually installed.
mapr-mapreduce2 is already the newest version.
mapr-mapreduce2 set to manually installed.
mapr-nfs is already the newest version.
mapr-tasktracker is already the newest version.
mapr-webserver is already the newest version.
mapr-zk-internal is already the newest version.
mapr-zk-internal set to manually installed.
mapr-zookeeper is already the newest version.
mapr-oozie is already the newest version.
mapr-oozie-internal is already the newest version.


Any ideas/suggestions to fix this?

BR,
Varun

On Sun, Oct 18, 2015 at 1:22 PM, varun bhatnagar 
wrote:

> Hi Chris,
>
> Thanks for the suggestion. I have posted my question on his blog but it is
> not yet approved and is still in pending state.
> Is it possible to provide any other suggestion to solve this problem. I am
> really out of ideas at the moment and I reallt want to fix this problem as
> my actual work is on hold.
>
> Can anyone please suggest something else?
>
> BR,
> Varun
>
> On Fri, Oct 16, 2015 at 7:07 PM, Chris Buccella <
> chris.bucce...@antallagon.com> wrote:
>
>> Those "No route to host" log messages are DEBUG level; they don't
>> indicate a problem per say, it may just be that the instance didn't come up
>> yet. If the cluster transitioned from Waiting to Configuring, I assume the
>> instance did become accessible.
>>
>> You might try reaching out to Abizer, the author of the blog, directly.
>>
>> On Fri, Oct 16, 2015 at 8:36 AM, varun bhatnagar 
>> wrote:
>>
>>> Hi,
>>>
>>> Now I have tried launching one more cluster with having 1 instance (All
>>> in one setup). When the cluster was in "Waiting" state but I saw the below
>>> messages getting logged in sahara log file:
>>>
>>> 2015-10-16 13:21:00.045 27689 DEBUG sahara.service.engine [-] Can't
>>> login to node mymapr-allinone-001 172.24.4.235, reason error: [Errno 113]
>>> No route to host _is_accessible
>>> /usr/lib/python2.7/site-packages/sahara/service/engine.py:128
>>> 2015-10-16 13:21:08.702 27689 DEBUG sahara.service.engine [-] Can't
>>> login to node mymapr-allinone-001 172.24.4.235, reason error: [Errno 113]
>>> No route to host _is_accessible
>>> /usr/lib/python2.7/site-packages/sahara/service/engine.py:128
>>> 2015-10-16 13:21:17.106 27689 DEBUG sahara.service.engine [-] Can't
>>> login to node mymapr-allinone-001 172.24.4.235, reason error: [Errno 113]
>>> No route to host _is_accessible
>>> /usr/lib/python2.7/site-packages/sahara/service/engine.py:128
>>>
>>> The instance was running and was reachable by floating IP and ssh also
>>> works fine then why is this message being thrown by Sahara?
>>>
>>>
>>> [root@controller ~(keystone_admin)]# nova list
>>>
>>> +--+-+++-+--+
>>> | ID   | Name| Status |
>>> Task State | Power State | Networks |
>>>
>>> 

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

[openstack-announce] [release][stable][glance] python-glanceclient release 0.14.3 (juno)

[doug]

We are pumped to announce the release of:

python-glanceclient 0.14.3: OpenStack Image API Client Library

This release is part of the juno stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/python-glanceclient

With package available at:

https://pypi.python.org/pypi/python-glanceclient

For more details, please see the git log history below and:

http://launchpad.net/python-glanceclient/+milestone/0.14.3

Please report issues through launchpad:

http://bugs.launchpad.net/python-glanceclient

Notable changes


Syncs up requirements with global-requirements in stable/juno.

Changes in python-glanceclient 0.14.2..0.14.3
-

cfa75ce Update .gitreview for stable/juno
5d276b6 Updated from global requirements

Diffstat (except docs and test files)
-

.gitreview|  1 +
requirements.txt  | 18 +-
setup.py  |  1 -
test-requirements.txt | 18 +-
4 files changed, 19 insertions(+), 19 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 4e67c80..16646cb 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4,2 +4,2 @@
-pbr>=0.6,!=0.7,<1.0
-Babel>=1.3
+pbr!=0.7,<1.0,>=0.6
+Babel<=1.3,>=1.3
@@ -7,7 +7,7 @@ argparse
-PrettyTable>=0.7,<0.8
-python-keystoneclient>=0.10.0
-pyOpenSSL>=0.11
-requests>=1.2.1,!=2.4.0
-warlock>=1.0.1,<2
-six>=1.7.0
-oslo.utils>=1.0.0 # Apache-2.0
+PrettyTable<0.8,>=0.7
+python-keystoneclient<1.2.0,>=0.10.0
+pyOpenSSL<=0.13,>=0.11
+requests!=2.4.0,<=2.2.1,>=2.1.0
+warlock<2,>=1.0.1
+six<=1.9.0,>=1.7.0
+oslo.utils<1.5.0,>=1.4.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index db9ba39..f16ae9f 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -4 +4 @@
-hacking>=0.8.0,<0.9
+hacking<0.9,>=0.8.0
@@ -6,8 +6,8 @@ hacking>=0.8.0,<0.9
-coverage>=3.6
-discover
-mox3>=0.7.0
-mock>=1.0
-oslosphinx>=2.2.0.0a2
-sphinx>=1.1.2,!=1.2.0,<1.3
-testrepository>=0.0.18
-testtools>=0.9.34
+coverage<=3.7.1,>=3.6
+discover<=0.4.0
+mox3<=0.7.0,>=0.7.0
+mock<=1.0.1,>=1.0
+oslosphinx<2.5.0,>=2.2.0 # Apache-2.0
+sphinx!=1.2.0,<1.3,>=1.1.2
+testrepository<=0.0.20,>=0.0.18
+testtools!=1.4.0,<=1.5.0,>=0.9.34



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

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-announce] [release][oslo] oslo.service release 0.11.0 (mitaka)

[davanum]

We are eager to announce the release of:

oslo.service 0.11.0: oslo.service library

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.service

With package available at:

https://pypi.python.org/pypi/oslo.service

For more details, please see the git log history below and:

http://launchpad.net/oslo.service/+milestone/0.11.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.service

Changes in oslo.service 0.10.0..0.11.0
--

8aa90b5 Updated from global requirements
91a92f0 Add doc8 to py27 tox env and fix raised issues
f566c54 Document termination of children on SIGHUP
5573508 Updated from global requirements
5832c6f Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt  |  2 +-
test-requirements.txt |  3 ++-
tox.ini   |  5 +
4 files changed, 41 insertions(+), 23 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 54c954a..806b7a8 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -10 +10 @@ monotonic>=0.3 # Apache-2.0
-oslo.utils>=2.0.0 # Apache-2.0
+oslo.utils>=2.4.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 8fabf39..7307556 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ oslotest>=1.10.0 # Apache-2.0
-# These are needed for docs generation
+# These are needed for docs generation/testing
@@ -11,0 +12 @@ sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2
+doc8 # Apache-2.0



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [release][oslo] oslo.middleware release 2.10.0 (mitaka)

[davanum]

We are thrilled to announce the release of:

oslo.middleware 2.10.0: Oslo Middleware library

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.middleware

With package available at:

https://pypi.python.org/pypi/oslo.middleware

For more details, please see the git log history below and:

http://launchpad.net/oslo.middleware/+milestone/2.10.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.middleware

Changes in oslo.middleware 2.9.0..2.10.0


8a89230 Updated from global requirements
023f521 Updated from global requirements
e6f096b Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index d2dba26..e351493 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12 +12 @@ oslo.i18n>=1.5.0 # Apache-2.0
-oslo.utils>=2.0.0 # Apache-2.0
+oslo.utils>=2.4.0 # Apache-2.0



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[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-announce] [release][oslo] oslo.config release 2.6.0 (mitaka)

[davanum]

We are excited to announce the release of:

oslo.config 2.6.0: Oslo Configuration API

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.config

With package available at:

https://pypi.python.org/pypi/oslo.config

For more details, please see the git log history below and:

http://launchpad.net/oslo.config/+milestone/2.6.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.config

Changes in oslo.config 2.5.0..2.6.0
---

ee2bab6 Add PortOpt for integer with range 1 to 65535
419311c Add missing tests and generator code for IPOpt

Diffstat (except docs and test files)
-

oslo_config/cfg.py  | 13 +++
oslo_config/generator.py|  5 +++-
5 files changed, 94 insertions(+), 1 deletion(-)



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [release][oslo] debtcollector release 0.10.0 (mitaka)

[davanum]

We are excited to announce the release of:

debtcollector 0.10.0: A collection of Python deprecation patterns and
strategies that help you collect your technical debt in a non-
destructive manner.

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/debtcollector

With package available at:

https://pypi.python.org/pypi/debtcollector

For more details, please see the git log history below and:

http://launchpad.net/debtcollector/+milestone/0.10.0

Please report issues through launchpad:

http://bugs.launchpad.net/debtcollector

Changes in debtcollector 0.9.0..0.10.0
--

5fc9662 Add ability to disable warnings being emitted
3ab532f Add a 'removed_property' descriptor class

Diffstat (except docs and test files)
-

debtcollector/_utils.py |   3 +
debtcollector/fixtures/__init__.py  |   0
debtcollector/fixtures/disable.py   |  39 +
debtcollector/removals.py   | 145 ++--
test-requirements.txt   |   1 +
8 files changed, 275 insertions(+), 5 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index d3cad4e..7b339e7 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15,0 +16 @@ testtools>=1.4.0
+fixtures>=1.3.1



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [release][nova] python-novaclient release 2.32.0 (mitaka)

[doug]

We are delighted to announce the release of:

python-novaclient 2.32.0: Client library for OpenStack Compute API

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/python-novaclient

With package available at:

https://pypi.python.org/pypi/python-novaclient

For more details, please see the git log history below and:

http://launchpad.net/python-novaclient/+milestone/2.32.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-novaclient

Notable changes


Bug fixes and dependency updates. Note d045019 which sets the default 
--os-compute-api-version to 2.5 for the CLI rather than 2.latest.

Changes in python-novaclient 2.31.0..2.32.0
---

469d068 Revert "Allow display project-id for server groups"
4bd50d5 Test that microversions are not skipped
3697782 Updated from global requirements
d045019 Set DEFAULT_OS_COMPUTE_API_VERSION to 2.5
3866bfb Add --metadata as optional input when do nova image-create
3b0e81e Use dictionary literal for dictionary creation

Diffstat (except docs and test files)
-

novaclient/__init__.py |  6 +
novaclient/shell.py| 11 -
novaclient/v2/shell.py | 24 +--
test-requirements.txt  |  2 +-
6 files changed, 77 insertions(+), 16 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 3bb675e..141d8d1 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -18 +18 @@ testtools>=1.4.0
-tempest-lib>=0.8.0
+tempest-lib>=0.9.0



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[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

[openstack-announce] [release][oslo] taskflow release 1.23.0 (mitaka)

[davanum]

We are pumped to announce the release of:

taskflow 1.23.0: Taskflow structured state management library.

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/taskflow

With package available at:

https://pypi.python.org/pypi/taskflow

For more details, please see the git log history below and:

http://launchpad.net/taskflow/+milestone/1.23.0

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

Changes in taskflow 1.22.0..1.23.0
--

dd22aff Updated from global requirements
5f5fdd1 feat: add max_dispatches arg to conductor's run
9658952 Make more of the WBE logging and '__repr__' message more useful
2566709 Fix bad sphinx module reference
6f6e9a3 Relabel internal engine 'event' -> 'outcome'
6170dea No need for Oslo Incubator Sync
75517eb Use the node built-in 'dfs_iter' instead of recursion
dc0bdb5 Fix 'dependened upon' spelling error
f6450d9 Fix how the dir persistence backend was not listing logbooks
bedd238 Avoid running this example if zookeeper is not found

Diffstat (except docs and test files)
-

openstack-common.conf  |  4 ---
requirements.txt   |  2 +-
taskflow/conductors/backends/impl_blocking.py  | 34 ++
taskflow/engines/action_engine/builder.py  |  8 ++---
taskflow/engines/action_engine/completer.py| 16 -
taskflow/engines/action_engine/executor.py |  2 +-
taskflow/engines/action_engine/scopes.py   | 18 +-
taskflow/engines/worker_based/executor.py  |  4 +--
taskflow/engines/worker_based/protocol.py  | 15 ++--
taskflow/engines/worker_based/types.py | 18 +-
taskflow/examples/99_bottles.py| 23 ++--
taskflow/persistence/backends/impl_dir.py  |  8 +++--
taskflow/types/failure.py  |  2 +-
taskflow/types/tree.py | 48 ++
taskflow/utils/iter_utils.py   | 15 
19 files changed, 219 insertions(+), 73 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 60cc083..0bdbf29 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -44 +44 @@ automaton>=0.5.0 # Apache-2.0
-oslo.utils>=2.0.0 # Apache-2.0
+oslo.utils>=2.4.0 # Apache-2.0



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[Openstack] EC2-API and OpenStack

[Georgios Dimitrakakis]

All,

I am trying to integrate EC2-API (https://github.com/openstack/ec2-api) 
with my OpenStack environment (Icehouse on CentOS).


So far I have built EC2-API on the virtual environment (using Python 
2.7.9) and have started successfully the ec2-api, ec2-api-metadata an 
ec2-api-s3 services.


When querying and there are no volumes in the installation I am getting 
the correct response: "No volumes found"


Unfortunately when there are volumes I cannot list them and the result 
is this:



2015-10-19 20:23:54.534 ERROR ec2api.api 
[req-ad3b40aa-8ea4-49c5-b1d5-ab02ea04c906 admin admin] Unexpected 
AttributeError raised: encrypted
2015-10-19 20:23:54.534 16908 ERROR ec2api.api Traceback (most recent 
call last):
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/__init__.py", line 390, 
in __call__
2015-10-19 20:23:54.534 16908 ERROR ec2api.api result = 
api_request.invoke(context)
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/apirequest.py", line 
84, in invoke
2015-10-19 20:23:54.534 16908 ERROR ec2api.api result = 
method(context, **args)
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/cloud.py", line 78, in 
func_wrapped
2015-10-19 20:23:54.534 16908 ERROR ec2api.api return 
impl_func(context, **kwargs)
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/volume.py", line 171, 
in describe_volumes
2015-10-19 20:23:54.534 16908 ERROR ec2api.api 
max_results=max_results, next_token=next_token)
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/common.py", line 481, 
in describe
2015-10-19 20:23:54.534 16908 ERROR ec2api.api 
max_results=max_results, next_token=next_token)
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/common.py", line 416, 
in describe
2015-10-19 20:23:54.534 16908 ERROR ec2api.api formatted_item = 
self.format(item, os_item)
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/volume.py", line 140, 
in format

2015-10-19 20:23:54.534 16908 ERROR ec2api.api self.snapshots)
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/volume.py", line 192, 
in _format_volume
2015-10-19 20:23:54.534 16908 ERROR ec2api.api 'encrypted': 
os_volume.encrypted,
2015-10-19 20:23:54.534 16908 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/.venv/lib/python2.7/site-packages/cinderclient/openstack/common/apiclient/base.py", 
line 463, in __getattr__
2015-10-19 20:23:54.534 16908 ERROR ec2api.api raise 
AttributeError(k)
2015-10-19 20:23:54.534 16908 ERROR ec2api.api AttributeError: 
encrypted

2015-10-19 20:23:54.534 16908 ERROR ec2api.api
2015-10-19 20:23:54.535 ERROR ec2api.api 
[req-ad3b40aa-8ea4-49c5-b1d5-ab02ea04c906 admin admin] Environment: 
{"CONTENT_TYPE": "application/x-www-form-urlencoded; charset=utf-8", 
"SCRIPT_NAME": "", "REQUEST_METHOD": "POST", "HTTP_HOST": 
"10.10.10.190:8788", "PATH_INFO": "/services/Cloud", 
"GATEWAY_INTERFACE": "CGI/1.1", "SERVER_PROTOCOL": "HTTP/1.0", 
"CONTENT_LENGTH": "231", "HTTP_USER_AGENT": "aws-sdk-nodejs/2.2.0 
linux/v0.10.35", "HTTP_CONNECTION": "keep-alive", "RAW_PATH_INFO": 
"/services/Cloud", "REMOTE_ADDR": "10.10.10.217", "REMOTE_PORT": 
"41786", "wsgi.url_scheme": "http", "SERVER_NAME": "10.10.10.190", 
"SERVER_PORT": "8788"}
2015-10-19 20:23:54.536 INFO ec2api.api 
[req-ad3b40aa-8ea4-49c5-b1d5-ab02ea04c906 admin admin] 0.538786s 
10.10.10.217 POST /services/Cloud DescribeVolumes 500 
[aws-sdk-nodejs/2.2.0 linux/v0.10.35] application/x-www-form-urlencoded 
text/xml
2015-10-19 20:23:54.537 INFO ec2api.wsgi.server 
[req-ad3b40aa-8ea4-49c5-b1d5-ab02ea04c906 admin admin] 10.10.10.217 
"POST /services/Cloud HTTP/1.1" status: 500 len: 351 time: 0.5396290
2015-10-19 20:23:55.115 ERROR ec2api.api 
[req-473ec7c6-7e17-46f2-85a2-a649c46d7d25 admin admin] Unexpected 
AttributeError raised: encrypted
2015-10-19 20:23:55.115 16904 ERROR ec2api.api Traceback (most recent 
call last):
2015-10-19 20:23:55.115 16904 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/__init__.py", line 390, 
in __call__
2015-10-19 20:23:55.115 16904 ERROR ec2api.api result = 
api_request.invoke(context)
2015-10-19 20:23:55.115 16904 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/apirequest.py", line 
84, in invoke
2015-10-19 20:23:55.115 16904 ERROR ec2api.api result = 
method(context, **args)
2015-10-19 20:23:55.115 16904 ERROR ec2api.api   File 
"/home/user1/EC2-API/Attempt2/ec2-api/ec2api/api/cloud.py", line 78, in 
func_wrapped
2015-10-19 20:23:55.115 16904 ERROR ec2api.api return 
impl_func(context, **kwargs)
2015-10-19 20:23:55.115 16904 ERROR 

[openstack-announce] [release][oslo] oslo.messaging release 2.7.0 (mitaka)

[davanum]

We are chuffed to announce the release of:

oslo.messaging 2.7.0: Oslo Messaging API

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.messaging

With package available at:

https://pypi.python.org/pypi/oslo.messaging

For more details, please see the git log history below and:

http://launchpad.net/oslo.messaging/+milestone/2.7.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.messaging

Changes in oslo.messaging 2.6.1..2.7.0
--

4f49b7e Updated from global requirements
c4efc9a Updated from global requirements
822217e Updated from global requirements
45d1cf1 Small grammar messaging fix
c68266b Use a condition (and/or a dummy one) instead of a lock
04b53f3 Updated from global requirements
23c68ca AMQP1.0: Turn off debug tracing when running tox
34d24b7 Workaround test stream corruption issue
123a037 Provide the executor 'wait' function a timeout and use it
383abe0 Add if condition for random.shuffle

Diffstat (except docs and test files)
-

.testr.conf  |  2 +-
oslo_messaging/_drivers/impl_rabbit.py   |  6 ++-
oslo_messaging/_executors/base.py| 14 --
oslo_messaging/_executors/impl_blocking.py   |  6 ++-
oslo_messaging/_executors/impl_pooledexecutor.py | 43 -
oslo_messaging/_utils.py | 23 +
oslo_messaging/server.py | 60 
requirements.txt |  4 +-
tox.ini  |  1 -
11 files changed, 156 insertions(+), 75 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8dc4842..f00a9dc 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11 +11 @@ oslo.log>=1.8.0 # Apache-2.0
-oslo.utils>=2.0.0 # Apache-2.0
+oslo.utils>=2.4.0 # Apache-2.0
@@ -13 +13 @@ oslo.serialization>=1.4.0 # Apache-2.0
-oslo.service>=0.9.0 # Apache-2.0
+oslo.service>=0.10.0 # Apache-2.0



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[Openstack-operators] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-operators][openstack-dev][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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-announce] [release][keystone] keystoneauth release 1.2.0 (mitaka)

[davanum]

We are overjoyed to announce the release of:

keystoneauth 1.2.0: Authentication Library for OpenStack Identity

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystoneauth

With package available at:

https://pypi.python.org/pypi/keystoneauth1

For more details, please see the git log history below and:

http://launchpad.net/keystoneauth/+milestone/1.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

Changes in keystoneauth1 1.1.0..1.2.0
-

4fd8531 Expose bind data via AccessInfo
14a2586 Return None from generic plugin if failure
3ccc374 Updated from global requirements
b2484fd Copy AccessInfo tests from keystoneclient
54c0c6a Fix deprecated options in oslo_config
d6ffc5b Updated from global requirements
67280cb Add url as a deprecated alias for endpoint
8f68031 Updated from global requirements
7bb7f56 auto-generate release history
e264bdb Make RST section delineation length match title
e212009 Remove "Features" section from README
cddd78f Update the project description
10c5961 Make __all__ immutable
f1885f0 Add UnknownConnectionError to __all__
662394b remove references to keystone CLI
280a912 Add shields.io version/downloads links/badges into README.rst
45a95b6 Allow fetching oslo.config Opts from plugins
a0e1d74 Fix doc session example
b3a454c add openid connect plugins
3915102 Change ignore-errors to ignore_errors
4501513 Updated from global requirements

Diffstat (except docs and test files)
-

.coveragerc|   2 +-
README.rst |  27 ++-
keystoneauth1/access/__init__.py   |   4 +-
keystoneauth1/access/access.py |  39 ++-
keystoneauth1/exceptions/auth_plugins.py   |   4 +-
keystoneauth1/exceptions/base.py   |   2 +-
keystoneauth1/exceptions/catalog.py|   4 +-
keystoneauth1/exceptions/connection.py |   5 +-
keystoneauth1/exceptions/discovery.py  |   4 +-
keystoneauth1/exceptions/http.py   |   4 +-
keystoneauth1/exceptions/response.py   |   2 +-
keystoneauth1/exceptions/service_providers.py  |   2 +-
keystoneauth1/fixture/__init__.py  |   4 +-
keystoneauth1/fixture/discovery.py |   4 +-
keystoneauth1/fixture/v2.py|   3 +
keystoneauth1/fixture/v3.py|   3 +
keystoneauth1/identity/__init__.py |   9 +-
keystoneauth1/identity/generic/__init__.py |   4 +-
keystoneauth1/identity/generic/password.py |   4 +-
keystoneauth1/identity/v3/__init__.py  |   8 +-
keystoneauth1/identity/v3/base.py  |   2 +-
keystoneauth1/identity/v3/federation.py|   2 +-
keystoneauth1/identity/v3/k2k.py   |   2 +-
keystoneauth1/identity/v3/oidc.py  | 266 +
keystoneauth1/identity/v3/password.py  |   2 +-
keystoneauth1/identity/v3/token.py |   2 +-
keystoneauth1/loading/__init__.py  |   4 +-
keystoneauth1/loading/_plugins/admin_token.py  |   1 +
keystoneauth1/loading/_plugins/identity/v3.py  |  58 +
keystoneauth1/loading/base.py  |   4 +-
keystoneauth1/loading/cli.py   |   4 +-
keystoneauth1/loading/conf.py  |  18 +-
keystoneauth1/loading/opts.py  |   4 +-
keystoneauth1/loading/session.py   |   4 +-
requirements.txt   |   2 +-
setup.cfg  |   2 +
test-requirements.txt  |   4 +-
51 files changed, 1175 insertions(+), 252 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index f1e4df1..54b348c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ iso8601>=0.1.9
-requests>=2.5.2
+requests!=2.8.0,>=2.5.2
diff --git a/test-requirements.txt b/test-requirements.txt
index dc735af..186bac7 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -17 +17 @@ oslotest>=1.10.0 # Apache-2.0
-os-testr>=0.1.0
+os-testr>=0.4.1
@@ -21 +21 @@ sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2
-tempest-lib>=0.6.1
+tempest-lib>=0.10.0



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [release][oslo] mox3 release 0.12.0 (mitaka)

[davanum]

We are pumped to announce the release of:

mox3 0.12.0: Mock object framework for Python

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/mox3

With package available at:

https://pypi.python.org/pypi/mox3

For more details, please see the git log history below and:

http://launchpad.net/python-mox3/+milestone/0.12.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-mox3

Changes in mox3 0.11.0..0.12.0
--

eee957e Add universal wheel tag to setup.cfg
4c22360 Activate pep8 check that _ is imported

Diffstat (except docs and test files)
-

setup.cfg | 3 +++
tox.ini   | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [release][oslo] oslo.db release 3.1.0 (mitaka)

[davanum]

We are content to announce the release of:

oslo.db 3.1.0: Oslo Database library

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.db

With package available at:

https://pypi.python.org/pypi/oslo.db

For more details, please see the git log history below and:

http://launchpad.net/oslo.db/+milestone/3.1.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.db

Changes in oslo.db 3.0.0..3.1.0
---

3afd58f Updated from global requirements
4454f6b Updated from global requirements
29b626f Add debug logging for DB retry attempt.
4b145cf Fix the home-page value with Oslo wiki page

Diffstat (except docs and test files)
-

oslo_db/api.py| 3 +++
requirements.txt  | 2 +-
setup.cfg | 4 ++--
test-requirements.txt | 2 +-
4 files changed, 7 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index d8910b3..55a6c55 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -12 +12 @@ oslo.context>=0.2.0 # Apache-2.0
-oslo.utils>=2.0.0 # Apache-2.0
+oslo.utils>=2.4.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index d5ec183..9120fe6 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -21 +21 @@ testtools>=1.4.0
-tempest-lib>=0.9.0
+tempest-lib>=0.10.0



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [release][oslo] oslo.rootwrap release 2.5.0 (mitaka)

[davanum]

We are happy to announce the release of:

oslo.rootwrap 2.5.0: Oslo Rootwrap

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.rootwrap

With package available at:

https://pypi.python.org/pypi/oslo.rootwrap

For more details, please see the git log history below and:

http://launchpad.net/oslo.rootwrap/+milestone/2.5.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.rootwrap

Changes in oslo.rootwrap 2.4.0..2.5.0
-

31cfdbd Fix Python 3 support for eventlet monkey-patching
6f424f7 Fix Python 3 issues in tests

Diffstat (except docs and test files)
-

oslo_rootwrap/__init__.py  | 30 ++
oslo_rootwrap/client.py| 15 +++
oslo_rootwrap/daemon.py|  2 +-
oslo_rootwrap/wrapper.py   | 15 +++
setup.cfg  |  2 +-
tox.ini|  7 +--
9 files changed, 54 insertions(+), 37 deletions(-)



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [release][oslo] oslo.utils release 2.7.0 (mitaka)

[davanum]

We are jazzed to announce the release of:

oslo.utils 2.7.0: Oslo Utility library

This release is part of the mitaka release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.utils

With package available at:

https://pypi.python.org/pypi/oslo.utils

For more details, please see the git log history below and:

http://launchpad.net/oslo.utils/+milestone/2.7.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.utils

Changes in oslo.utils 2.6.0..2.7.0
--

e5a8182 Write document for each unit of oslo_utils.utils
babbb24 Fix usage of "deprecated" markup in docstrings
cb460ea Just use 'exception_to_unicode' to handle exception to string
9776cdd Add 'secret' to sensitive keys
9839152 Use a stopwatch in 'forever_retry_uncaught_exceptions'

Diffstat (except docs and test files)
-

oslo_utils/excutils.py|  63 +++---
oslo_utils/strutils.py|   2 +-
oslo_utils/timeutils.py   |  16 +++---
oslo_utils/units.py   |  16 ++
5 files changed, 133 insertions(+), 71 deletions(-)



___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

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