Re: [Openstack-operators] Forum in Boston - make some noise!

[lebre . adrien]

Dear Tom 

I would also appreciate to extend the deadline by a few days at least. 

Moreover, can you please elaborate a bit more about what is behind this 
etherpad? 

Like the Scientific and NFV WGs, I just added an etherpad link to start 
gathering  inputs/materials for the massively distributed (Fog/Edge) WG [1]
However, I'm not sure whether it should appear there or whether we should just 
exchanged the link through the MLs as we did it for the last cycles. 

In any case, we have our WG meeting next Wednesday and I will add this to our 
agenda (I hope we will be able to gather more inputs). 

Thanks
Ad_rien_

- Mail original -
> De: "Erik McCormick" 
> À: "Tom Fifield" 
> Cc: "OpenStack Operators" , 
> openst...@lists.openstack.org,
> user-commit...@lists.openstack.org
> Envoyé: Vendredi 10 Mars 2017 04:26:51
> Objet: Re: [Openstack-operators] Forum in Boston - make some noise!
> 
> 
> 
> Is there any possible way to push this deadline out a week? I ask
> only because my brain hurts focusing on sessions for the midcycle,
> and things will almost certainly come up in Milan that will spawn
> ideas for the forum.
> 
> 
> I know everything is on a tight schedule, but just wanted to throw
> this out there.
> 
> 
> Cheers,
> Erik
> 
> 
> 
> 
> On Mar 9, 2017 9:51 PM, "Tom Fifield" < t...@openstack.org > wrote:
> 
> 
> Hi all,
> 
> The end of brainstorming for our first Forum in Boston is fast
> approaching, and we need your help.
> 
> We don't have even close to enough topic suggestions on our etherpad
> to make the Forum a success :) We're also missing your +1 vote to
> show which sessions you'd like to see.
> 
> 
> 
> 
> ==> Please take 3 minutes to list any idea you want to discuss
> together as developers and users, and +1/-1 sessions to show your
> interest:
> 
> 
> https://etherpad.openstack.org/p/BOS-UC-brainstorming
> 
> 
> 
> We will close the etherpad on Tuesday, so time is tight!
> 
> 
> Once you've done that, you might like to share your ideas on the
> mailing list ...
> 
> 
> 
> 
> PS - If you want to learn more about the forum, check out:
> * http://superuser.openstack.org/articles/openstack-forum/
> * https://wiki.openstack.org/wiki/Forum
> 
> 
> 
> 
> Regards,
> 
> 
> Tom
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

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

[Openstack] [cinder][nova] Issue with live-migration on new Mitaka cloud using FC XIO storage

[Mike Smith]

Hello

We have a new Mitaka cloud in which we use fiber-channel storage (via EMC 
XtremIO) and Cinder.  Provisioning/deleting of instances works fine, but at the 
last stage of a live-migration operation the VM instance is left running on the 
new host with no Cinder volume due to failed paths.  I’m not certain how much 
of what I’m seeing is due to core Nova and Cinder functionality vs the specific 
Cinder driver for XtremIO and I would love some insight on that and the 
possible causes of what we’re seeing.   We use this same combination on our 
current Kilo based cloud without issue.

Here’s what happens:

- create a VM booted from volume.  In this case, it ended up on 
openstack-compute04 and runs succesfully

- Multipath status looks good:
[root@openstack-compute04] # 
multipath -ll
3514f0c5c0860003d dm-2 XtremIO ,XtremApp
size=20G features='0' hwhandler='0' wp=rw
`-+- policy='queue-length 0' prio=1 status=active
  |- 1:0:0:1  sdb 8:16 active ready running
  |- 1:0:1:1  sdc 8:32 active ready running
  |- 12:0:0:1 sdd 8:48 active ready running
  `- 12:0:1:1 sde 8:64 active ready running

- The /var/lib/scsi_id command (called by nova-rootwrap as we’ll see later) is 
able to determine scsi ids for these paths in /dev/disk/by-path:
[r...@openstack-compute04.a.pc.ostk.com
 by-path] # for i in `ls -1 | grep lun`; do echo $i; /lib/udev/scsi_id --page 
0x83 --whitelisted /dev/disk/by-path/$i; echo; done
pci-:03:00.0-fc-0x514f0c503187c700-lun-1
3514f0c5c0860003d

pci-:03:00.0-fc-0x514f0c503187c704-lun-1
3514f0c5c0860003d

pci-:03:00.1-fc-0x514f0c503187c701-lun-1
3514f0c5c0860003d

pci-:03:00.1-fc-0x514f0c503187c705-lun-1
3514f0c5c0860003d

- Now perform live-migration.  In this case, the instance moves to 
openstack-compute03:
[root@openstack-controller01] 
# nova live-migration 13c82fa9-828c-4289-8bfc-e36e42f79388

This fails.  The VM is left ‘running' on the new target host but has no disk 
because all the paths on the target host are failed.  They are properly removed 
from the original host.
[root@openstack-compute03] # 
virsh list --all
 IdName   State

 1 instance-00b5  running

- Failed paths also confirmed by multipath output:
[root@openstack-compute03] # 
multipath -ll
3514f0c5c0860003d dm-2 XtremIO ,XtremApp
size=20G features='0' hwhandler='0' wp=rw
`-+- policy='queue-length 0' prio=0 status=enabled
  |- 1:0:0:1  sdb 8:16 failed faulty running
  |- 1:0:1:1  sdc 8:32 failed faulty running
  |- 12:0:0:1 sdd 8:48 failed faulty running
  `- 12:0:1:1 sde 8:64 failed faulty running

- The error in the nova-compute log of the target host (openstack-compute03 in 
this case) points to the call made by nova-rootwrap, which receives a bad exit 
code when trying to get the scsi_id:

2017-03-09 21:02:07.364 2279 ERROR oslo_messaging.rpc.dispatcher Command: sudo 
nova-rootwrap /etc/nova/rootwrap.conf scsi_id --page 0x83 --whitelisted 
/dev/disk/by-path/pci-:03:00.0-fc-0x514f0c503187c700-lun-1
2017-03-09 21:02:07.364 2279 ERROR oslo_messaging.rpc.dispatcher Exit code: 1
2017-03-09 21:02:07.364 2279 ERROR oslo_messaging.rpc.dispatcher Stdout: u''
2017-03-09 21:02:07.364 2279 ERROR oslo_messaging.rpc.dispatcher Stderr: u''
2017-03-09 21:02:07.364 2279 ERROR oslo_messaging.rpc.dispatcher

...and in fact, running the scsi_id command directly (as was run previously on 
the original host) fails to return a scsi ID and returns with a non-successful 
“1” error code:

[root@openstack-compute03] # for 
i in `ls -1 | grep lun`; do echo $i; /lib/udev/scsi_id --page 0x83 
--whitelisted /dev/disk/by-path/$i; echo $?; echo; done
pci-:03:00.0-fc-0x514f0c503187c700-lun-1
1

pci-:03:00.0-fc-0x514f0c503187c704-lun-1
1

pci-:03:00.1-fc-0x514f0c503187c701-lun-1
1

pci-:03:00.1-fc-0x514f0c503187c705-lun-1
1

My assumption is that Nova is expecting those storage paths to be fully 
functional at the time it tries to determine the SCSI IDs and it can’t because 
the paths are faulty.  I will be reaching out to EMC’s support for this of 
course, but I also would like to get the groups thoughts on this.  I believe 
the XIO Cinder driver is responsible for making sure the storage paths are 
properly presented, but I don’t fully understand the relationship between what 
Nova is doing and what the Cinder driver does.

Any insight would be appreciated!

Mike Smith
Lead Cloud Systems Architect
Overstock.com



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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

Thanks, Steve!

I've put together an initial patch
https://review.openstack.org/#/c/444095/ which pulls in the
os-nova-servers module and a little extra to make it work in Horizon's
codebase. I've tried to make minimal edits to the actual code -
predominantly just editing module names. I've tested it and it mostly
works on Horizon's side \o/


 Richard

On 10 March 2017 at 14:40, McLellan, Steven  wrote:
> My expertise in this area is deeply suspect but as long as we maintain the
> mapping from the resource type names that searchlight uses (os-nova-servers)
> to the modules we'll be OK. If you or Rob put a patch up against horizon I
> (or a willing victim/volunteer) can test a searchlight-ui patch against it.
>
>
>  Original message 
> From: Richard Jones 
> Date: 3/9/17 21:13 (GMT-06:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type
> implementations
>
> Hey folks,
>
> Another potential issue is that the searchlight module structure and
> Horizon's module structure are different in a couple of respects. I
> could just retain the module structure from searchlight
> ('resources.os-nova-servers') or, preferably, I could rename those
> modules to match the Horizon structure more closely
> ('horizon.app.resources.os-nova-servers') or more strictly
> ('horizon.app.core.instances').
>
> As far as I can tell none of the module names are referenced directly
> outside of the module (apart from resources.module.js of course) so
> moving the modules shouldn't affect any existing usage in searchlight
> ui.
>
> We could bikeshed this for ages, so if I could just get Rob and Steve
> to wrestle over it or something, that'd be good. Rob's pretty scrappy.
>
>
>   Richard
>
>
> On 10 March 2017 at 09:56, Richard Jones  wrote:
>> OK, I will work on a plan that migrates the code into Horizon, thanks
>> everyone!
>>
>> Travis, can the searchlight details page stuff be done through
>> extending the base resource type in Horizon? If not, is that perhaps a
>> limitation of the extensible service?
>>
>>
>>  Richard
>>
>>
>> On 10 March 2017 at 02:20, McLellan, Steven 
>> wrote:
>>> I concur; option 4 is the only one makes sense to me and was what was
>>> intended originally. As long as we can do it in one fell swoop in one cyclle
>>> (preferably sooner than later) there should be no issues.
>>>
>>>
>>>
>>>
>>> On 3/9/17, 8:35 AM, "Tripp, Travis S"  wrote:
>>>
Let me get Matt B in on this discussion, but basically, option 4 is my
 initial feeling as Rob stated.

One downside we saw with this approach is that we weren’t going to be
 able to take advantage of searchlight capabilities in details pages if
 everything was in native horizon.  Although, I suppose that could be done 
 by
 using the hz-if-services directive [0] if horizon will allow searchlight
 optimized code to be in the horizon repo.

[0]
 https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js

-Travis

On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)" 
 wrote:

I tried searching the meeting logs but couldn’t find where we
 discussed this in the Searchlight meeting. The conclusion at the time was
 option 4 IIRC. The main thing is to make sure we get it done within one
 cycle, even if it isn’t default. this means searchlight-ui doesn’t have to
 carry some horrible workarounds and can just remove the code from their
 repo.

Basically; start putting the code in the Horizon repo, and when its
 done, Searchlight-UI can remove it from their repo.

Rob


> On 9 Mar 2017, at 04:22, Richard Jones 
 wrote:
>
> Hi Searchlight and Horizon folks,
>
> I'd like to re-use the wonderful resource type code from
> searchlight-ui (in particular os-nova-servers right now but
> potentially others down the track) and was wondering whether you'd
 had
> any thoughts about how we might share that code? Off the top of my
> head I see a few options:
>
> 1. We depend on the searchlight-ui as a Horizon requirement; this
 is
> pretty unlikely to happen (depending on any optional panel means
 it's
> not really optional any longer ;-)
> 2. We copy the code from searchlight-ui into Horizon; this is
 pretty terrible.
> 3. We move the code from searchlight-ui into a separate project
 that
> both Horizon and searchlight-ui depend upon; this could be made to
> work, though it's Yet Another Project.
> 4. We move the code 

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Joshua Harlow]

Renat Akhmerov wrote:



On 10 Mar 2017, at 06:02, Zane Bitter > wrote:

On 08/03/17 11:23, David Moreau Simard wrote:

The App Catalog, to me, sounds sort of like a weird message that
OpenStack somehow requires applications to be
packaged/installed/deployed differently.
If anything, perhaps we should spend more effort on advertising that
OpenStack provides bare metal or virtual compute resources and that
apps will work just like any other places.


Look, it's true that legacy apps from the 90s will run on any VM you
can give them. But the rest of the world has spent the last 15 years
moving on from that. Applications of the future, and increasingly the
present, span multiple VMs/containers, make use of services provided
by the cloud, and interact with their own infrastructure. And users
absolutely will need ways of packaging and deploying them that work
with the underlying infrastructure. Even those apps from the 90s
should be taking advantage of things like e.g. Neutron security
groups, configuration of which is and will always be out of scope for
Docker Hub images.

So no, we should NOT spend more effort on advertising that we aim to
become to cloud what Subversion is to version control. We've done far
too much of that already IMHO.


100% agree with that.

And this whole discussion is taking me to the question: is there really
any officially accepted strategy for OpenStack for 1, 3, 5 years?


I can propose what I would like for a strategy (it's not more VMs and 
more neutron security groups...), though if it involves (more) design by 
committee, count me out.


I honestly believe we have to do the equivalent of a technology leapfrog 
if we actually want to be relevant; but maybe I'm to eager...


Is

there any ultimate community goal we’re moving to regardless of
underlying technologies (containers, virtualization etc.)? I know we’re
now considering various community goals like transition to Python 3.5
etc. but these goals don’t tell anything about our future as an IT
ecosystem from user perspective. I may assume that I’m just not aware of
it. I’d be glad if it was true. I’m eager to know the answers for these
questions. Overall, to me it feels like every company in the community
just tries to pursue its own short-term (in the best case mid-term)
goals without really caring about long-term common goals. So if we say
OpenStack is a car then it seems like the wheels of this car are moving
in different directions. Again, I’d be glad if it wasn’t true. So maybe
some governance needed around setting and achieving ultimate goals of
OpenStack? Or if they already exist we need to better explain them and
advertise publicly? That in turn IMO could attract more businesses and
contributors.

Renat Akhmerov
@Nokia

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


__
OpenStack Development Mailing List (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][ptg] Following up on Pike PTG sessions

[Renat Akhmerov]

Hi,

Below is the list of blueprints and bugs updated after the PTG discussions. The 
etherpad containing all sessions’ info and notes is at [1].

Scalability, Fault Tolerance and HA
https://blueprints.launchpad.net/mistral/+spec/mistral-ha-gate 

https://blueprints.launchpad.net/mistral/+spec/mistral-multinode-tests 

https://blueprints.launchpad.net/mistral/+spec/mistral-fault-tolerance 

Running actions by engine
https://blueprints.launchpad.net/mistral/+spec/mistral-actions-run-by-engine 
 
Actions API
https://blueprints.launchpad.net/mistral/+spec/mistral-custom-actions-api 

Workflow error analysis
https://blueprints.launchpad.net/mistral/+spec/mistral-error-analysis 

Mistral/Glare integration
https://blueprints.launchpad.net/mistral/+spec/mistral-glare-actions 

https://blueprints.launchpad.net/mistral/+spec/mistral-glare-resources 

Working with sensitive data
https://bugs.launchpad.net/mistral/+bug/1337268 

Dynamic actions
https://blueprints.launchpad.net/mistral/+spec/mistral-dynamic-actions 

Task explicit parameters
https://blueprints.launchpad.net/mistral/+spec/mistral-explicit-task-parameters 



I’d like to ask the team to review these LP tickets, at least those you’re 
interested in.
At the next weekly meeting we’ll go over these items and 
prioritize/scope/assign them.
I would also like to reevaluate priorities of other tasks that are now formally 
scoped for
Pike cycle. The expected result is to build a roadmap for Pike next week.


[1]  https://etherpad.openstack.org/p/mistral-ptg-pike 


Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Renat Akhmerov]

> On 10 Mar 2017, at 06:02, Zane Bitter  wrote:
> 
> On 08/03/17 11:23, David Moreau Simard wrote:
>> The App Catalog, to me, sounds sort of like a weird message that
>> OpenStack somehow requires applications to be
>> packaged/installed/deployed differently.
>> If anything, perhaps we should spend more effort on advertising that
>> OpenStack provides bare metal or virtual compute resources and that
>> apps will work just like any other places.
> 
> Look, it's true that legacy apps from the 90s will run on any VM you can give 
> them. But the rest of the world has spent the last 15 years moving on from 
> that. Applications of the future, and increasingly the present, span multiple 
> VMs/containers, make use of services provided by the cloud, and interact with 
> their own infrastructure. And users absolutely will need ways of packaging 
> and deploying them that work with the underlying infrastructure. Even those 
> apps from the 90s should be taking advantage of things like e.g. Neutron 
> security groups, configuration of which is and will always be out of scope 
> for Docker Hub images.
> 
> So no, we should NOT spend more effort on advertising that we aim to become 
> to cloud what Subversion is to version control. We've done far too much of 
> that already IMHO.

100% agree with that.

And this whole discussion is taking me to the question: is there really any 
officially accepted strategy for OpenStack for 1, 3, 5 years? Is there any 
ultimate community goal we’re moving to regardless of underlying technologies 
(containers, virtualization etc.)? I know we’re now considering various 
community goals like transition to Python 3.5 etc. but these goals don’t tell 
anything about our future as an IT ecosystem from user perspective. I may 
assume that I’m just not aware of it. I’d be glad if it was true. I’m eager to 
know the answers for these questions. Overall, to me it feels like every 
company in the community just tries to pursue its own short-term (in the best 
case mid-term) goals without really caring about long-term common goals. So if 
we say OpenStack is a car then it seems like the wheels of this car are moving 
in different directions. Again, I’d be glad if it wasn’t true. So maybe some 
governance needed around setting and achieving ultimate goals of OpenStack? Or 
if they already exist we need to better explain them and advertise publicly? 
That in turn IMO could attract more businesses and contributors.

Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [mistral] Mistral Custom Actions API Design

[Renat Akhmerov]

Hi,

I probably like the base class approach better too.

However, I’m trying to understand if we need this variety of classes.
Do we need a separate class for asynchronous actions? IMO, since is_sync() is 
just an instance method that can potentially return both True and False based 
on the instance state shouldn’t be introduced by a special class. Otherwise 
it’s confusing that a classes declared as AsyncAction can actually be 
synchronous (if its is_sync() returns True). So maybe we should just leave this 
method in the base class.
I”m also wondering if we should just always pass “context” into run() method. 
Those action implementations that don’t need it could just ignore it. Not sure 
though.

As far as mixin approach, I’d say I’d be ok with having mixing for 
context-based actions. Although, like Dougal said, it may be a little harder to 
read, this approach gives a huge flexibility for long term. Imagine if we want 
to have a class of actions that some different kind of information. Just making 
it up… For example, some of my actions need to be aware of some policies 
(Congress-like) or information about metrics of the current operating system 
(this is probably a bad example because it’s easy to use standard Python 
modules but I’m just trying to illustrate the idea). In this case we could have 
PolicyMixin and OperatingSystemMixin that would set required info into the 
instance state or provide with handle interfaces for more advanced uses.

What do you think?

Renat Akhmerov
@Nokia

> On 9 Mar 2017, at 11:35, Ryan Brady  wrote:
> 
> At the PTG and previous discussions in IRC, I mentioned there were two 
> different design ideas I had for the developer experience for custom action 
> development in mistral-lib.  The purpose and intent behind the patch[1] was 
> discussed in person at the PTG and that was helpful for me wrt to scope.  I 
> feel it would be helpful to discuss and decide together the final piece of 
> this patch.  I'd like to get any feedback on either of these two ideas as 
> they will shape how developers integrate with Mistral in the future, impact 
> our OpenStack integration efforts in mistral-extra.  Nothing stops a 
> developer from adopting either style in their custom action libraries, but 
> most will likely want to remain consistent with style present in the upstream 
> code.
> 
> I have created separate declaration and usage examples in hopes of 
> illustrating some of the similarities and differences.  To me it seems the 
> base class example is more declarative/explicit, but the mixin example is 
> more extensible and dry.  Both examples reflect on backwards compatibility 
> and possible changes to how mistral checks for sync/async actions and how to 
> pass the context (as needed by actions that integrate with OpenStack).
> 
> 
> base classes declaration: 
> https://gist.github.com/rbrady/ff86c484e8e6e53ba2dc3dfa17b01b09 
> 
> 
> base class usage: 
> https://gist.github.com/rbrady/716a02fb2bd38d822c6df8bd642d3ea6 
> 
> 
> mixins declaration: 
> https://gist.github.com/rbrady/d30ae640b19df658a17cd93827125678 
> 
> 
> mixins usage: https://gist.github.com/rbrady/248cb52d5c5f94854d8c76eee911ce8e 
> 
> 
> 
> Thanks,
> 
> Ryan
> 
> -- 
> Ryan Brady
> Cloud Engineering
> rbr...@redhat.com  
> 919.890.8925
> 
> 
> [1] https://review.openstack.org/#/c/411412/ 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[McLellan, Steven]

My expertise in this area is deeply suspect but as long as we maintain the 
mapping from the resource type names that searchlight uses (os-nova-servers) to 
the modules we'll be OK. If you or Rob put a patch up against horizon I (or a 
willing victim/volunteer) can test a searchlight-ui patch against it.

 Original message 
From: Richard Jones 
Date: 3/9/17 21:13 (GMT-06:00)
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type 
implementations

Hey folks,

Another potential issue is that the searchlight module structure and
Horizon's module structure are different in a couple of respects. I
could just retain the module structure from searchlight
('resources.os-nova-servers') or, preferably, I could rename those
modules to match the Horizon structure more closely
('horizon.app.resources.os-nova-servers') or more strictly
('horizon.app.core.instances').

As far as I can tell none of the module names are referenced directly
outside of the module (apart from resources.module.js of course) so
moving the modules shouldn't affect any existing usage in searchlight
ui.

We could bikeshed this for ages, so if I could just get Rob and Steve
to wrestle over it or something, that'd be good. Rob's pretty scrappy.


  Richard


On 10 March 2017 at 09:56, Richard Jones  wrote:
> OK, I will work on a plan that migrates the code into Horizon, thanks 
> everyone!
>
> Travis, can the searchlight details page stuff be done through
> extending the base resource type in Horizon? If not, is that perhaps a
> limitation of the extensible service?
>
>
>  Richard
>
>
> On 10 March 2017 at 02:20, McLellan, Steven  wrote:
>> I concur; option 4 is the only one makes sense to me and was what was 
>> intended originally. As long as we can do it in one fell swoop in one cyclle 
>> (preferably sooner than later) there should be no issues.
>>
>>
>>
>>
>> On 3/9/17, 8:35 AM, "Tripp, Travis S"  wrote:
>>
>>>Let me get Matt B in on this discussion, but basically, option 4 is my 
>>>initial feeling as Rob stated.
>>>
>>>One downside we saw with this approach is that we weren’t going to be able 
>>>to take advantage of searchlight capabilities in details pages if everything 
>>>was in native horizon.  Although, I suppose that could be done by using the 
>>>hz-if-services directive [0] if horizon will allow searchlight optimized 
>>>code to be in the horizon repo.
>>>
>>>[0] 
>>>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>>
>>>-Travis
>>>
>>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:
>>>
>>>I tried searching the meeting logs but couldn’t find where we discussed 
>>> this in the Searchlight meeting. The conclusion at the time was option 4 
>>> IIRC. The main thing is to make sure we get it done within one cycle, even 
>>> if it isn’t default. this means searchlight-ui doesn’t have to carry some 
>>> horrible workarounds and can just remove the code from their repo.
>>>
>>>Basically; start putting the code in the Horizon repo, and when its 
>>> done, Searchlight-UI can remove it from their repo.
>>>
>>>Rob
>>>
>>>
>>>> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
>>>>
>>>> Hi Searchlight and Horizon folks,
>>>>
>>>> I'd like to re-use the wonderful resource type code from
>>>> searchlight-ui (in particular os-nova-servers right now but
>>>> potentially others down the track) and was wondering whether you'd had
>>>> any thoughts about how we might share that code? Off the top of my
>>>> head I see a few options:
>>>>
>>>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>>>> pretty unlikely to happen (depending on any optional panel means it's
>>>> not really optional any longer ;-)
>>>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
>>> terrible.
>>>> 3. We move the code from searchlight-ui into a separate project that
>>>> both Horizon and searchlight-ui depend upon; this could be made to
>>>> work, though it's Yet Another Project.
>>>> 4. We move the code from searchlight-ui into Horizon. I think this is
>>>> most likely to work.
>>>>
>>>> What are your thoughts? Have I missed an option in this list that you
>>>> think is a better one? Have I missed the mark in my analysis of the
>>>> options I've presented?
>>>>
>>>>
>>>>  Richard
>>>>
>>>> 
>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> 

Re: [Openstack] [Openstack-operators] Forum in Boston - make some noise!

[Erik McCormick]

Is there any possible way to push this deadline out a week? I ask only
because my brain hurts focusing on sessions for the midcycle, and things
will almost certainly come up in Milan that will spawn ideas for the forum.

I know everything is on a tight schedule, but just wanted to throw this out
there.

Cheers,
Erik


On Mar 9, 2017 9:51 PM, "Tom Fifield"  wrote:

> Hi all,
>
> The end of brainstorming for our first Forum in Boston is fast
> approaching, and we need your help.
>
> We don't have even close to enough topic suggestions on our etherpad to
> make the Forum a success :) We're also missing your +1 vote to show which
> sessions you'd like to see.
>
>
>
>
> ==> Please take 3 minutes to list any idea you want to discuss together as
> developers and users, and +1/-1 sessions to show your interest:
>
>
> https://etherpad.openstack.org/p/BOS-UC-brainstorming
>
>
>
> We will close the etherpad on Tuesday, so time is tight!
>
>
> Once you've done that, you might like to share your ideas on the mailing
> list ...
>
>
>
>
> PS - If you want to learn more about the forum, check out:
> * http://superuser.openstack.org/articles/openstack-forum/
> * https://wiki.openstack.org/wiki/Forum
>
>
>
>
> Regards,
>
>
> Tom
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
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] [all][api] POST /api-wg/news

[Everett Toews]

> On Mar 9, 2017, at 11:52 AM, Ed Leafe  wrote:
> 
> Greetings OpenStack community,
> 
> Today's meeting started on a heavyhearted note, as we hoisted our virtual 
> beers and gave a toast to Everett Toews, who recently had to step down from 
> his API-WG duties due to a job re-assignment.

I'm proud of everything we've accomplished to date and I know that there is a 
healthy future for the API Working Group. The API WG has made great strides in 
its mission [1]. Plus it sounds like the PTG sessions were very well attended 
and that's really heartening to hear after all of this time.

I wish the API WG all the best and it's been a pleasure working on this with 
everyone.

> For those who don't know, Everett and I started the API-WG a few years ago,

Umm...given this statement, I feel I _must_ provide some clarity.

The API WG was started by myself, Jay Pipes, and Chris Yeoh. The ball got 
rolling in this email thread [2]. One of our first artifacts was this wiki page 
[3]. The 3 of us were the original core members (I'm not sure if [4] is capable 
of displaying history). Then we started making commits to the repo [5]. I'll 
leave it as an exercise to the reader to determine who got involved, when they 
got involved, and in what capacity.

Ed has made a lot of contributions as of late and his efforts are genuinely 
appreciated. So much so that he became a core member and continues to drive the 
mission forward.

Cheers,
Everett

[1] http://specs.openstack.org/openstack/api-wg/#mission-statement
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/thread.html#46482
[3] 
https://wiki.openstack.org/w/index.php?title=API_Working_Group=20141114155251=history
[4] https://review.openstack.org/#/admin/groups/
[5] http://git.openstack.org/cgit/openstack/api-wg/log/?ofs=200


__
OpenStack Development Mailing 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-operators] Forum in Boston - make some noise!

[Erik McCormick]

Is there any possible way to push this deadline out a week? I ask only
because my brain hurts focusing on sessions for the midcycle, and things
will almost certainly come up in Milan that will spawn ideas for the forum.

I know everything is on a tight schedule, but just wanted to throw this out
there.

Cheers,
Erik


On Mar 9, 2017 9:51 PM, "Tom Fifield"  wrote:

> Hi all,
>
> The end of brainstorming for our first Forum in Boston is fast
> approaching, and we need your help.
>
> We don't have even close to enough topic suggestions on our etherpad to
> make the Forum a success :) We're also missing your +1 vote to show which
> sessions you'd like to see.
>
>
>
>
> ==> Please take 3 minutes to list any idea you want to discuss together as
> developers and users, and +1/-1 sessions to show your interest:
>
>
> https://etherpad.openstack.org/p/BOS-UC-brainstorming
>
>
>
> We will close the etherpad on Tuesday, so time is tight!
>
>
> Once you've done that, you might like to share your ideas on the mailing
> list ...
>
>
>
>
> PS - If you want to learn more about the forum, check out:
> * http://superuser.openstack.org/articles/openstack-forum/
> * https://wiki.openstack.org/wiki/Forum
>
>
>
>
> Regards,
>
>
> Tom
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

Hey folks,

Another potential issue is that the searchlight module structure and
Horizon's module structure are different in a couple of respects. I
could just retain the module structure from searchlight
('resources.os-nova-servers') or, preferably, I could rename those
modules to match the Horizon structure more closely
('horizon.app.resources.os-nova-servers') or more strictly
('horizon.app.core.instances').

As far as I can tell none of the module names are referenced directly
outside of the module (apart from resources.module.js of course) so
moving the modules shouldn't affect any existing usage in searchlight
ui.

We could bikeshed this for ages, so if I could just get Rob and Steve
to wrestle over it or something, that'd be good. Rob's pretty scrappy.


  Richard


On 10 March 2017 at 09:56, Richard Jones  wrote:
> OK, I will work on a plan that migrates the code into Horizon, thanks 
> everyone!
>
> Travis, can the searchlight details page stuff be done through
> extending the base resource type in Horizon? If not, is that perhaps a
> limitation of the extensible service?
>
>
>  Richard
>
>
> On 10 March 2017 at 02:20, McLellan, Steven  wrote:
>> I concur; option 4 is the only one makes sense to me and was what was 
>> intended originally. As long as we can do it in one fell swoop in one cyclle 
>> (preferably sooner than later) there should be no issues.
>>
>>
>>
>>
>> On 3/9/17, 8:35 AM, "Tripp, Travis S"  wrote:
>>
>>>Let me get Matt B in on this discussion, but basically, option 4 is my 
>>>initial feeling as Rob stated.
>>>
>>>One downside we saw with this approach is that we weren’t going to be able 
>>>to take advantage of searchlight capabilities in details pages if everything 
>>>was in native horizon.  Although, I suppose that could be done by using the 
>>>hz-if-services directive [0] if horizon will allow searchlight optimized 
>>>code to be in the horizon repo.
>>>
>>>[0] 
>>>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>>
>>>-Travis
>>>
>>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:
>>>
>>>I tried searching the meeting logs but couldn’t find where we discussed 
>>> this in the Searchlight meeting. The conclusion at the time was option 4 
>>> IIRC. The main thing is to make sure we get it done within one cycle, even 
>>> if it isn’t default. this means searchlight-ui doesn’t have to carry some 
>>> horrible workarounds and can just remove the code from their repo.
>>>
>>>Basically; start putting the code in the Horizon repo, and when its 
>>> done, Searchlight-UI can remove it from their repo.
>>>
>>>Rob
>>>
>>>
>>>> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
>>>>
>>>> Hi Searchlight and Horizon folks,
>>>>
>>>> I'd like to re-use the wonderful resource type code from
>>>> searchlight-ui (in particular os-nova-servers right now but
>>>> potentially others down the track) and was wondering whether you'd had
>>>> any thoughts about how we might share that code? Off the top of my
>>>> head I see a few options:
>>>>
>>>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>>>> pretty unlikely to happen (depending on any optional panel means it's
>>>> not really optional any longer ;-)
>>>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
>>> terrible.
>>>> 3. We move the code from searchlight-ui into a separate project that
>>>> both Horizon and searchlight-ui depend upon; this could be made to
>>>> work, though it's Yet Another Project.
>>>> 4. We move the code from searchlight-ui into Horizon. I think this is
>>>> most likely to work.
>>>>
>>>> What are your thoughts? Have I missed an option in this list that you
>>>> think is a better one? Have I missed the mark in my analysis of the
>>>> options I've presented?
>>>>
>>>>
>>>>  Richard
>>>>
>>>> 
>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> __
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>__
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[Openstack] Forum in Boston - make some noise!

[Tom Fifield]

Hi all,

The end of brainstorming for our first Forum in Boston is fast 
approaching, and we need your help.


We don't have even close to enough topic suggestions on our etherpad to 
make the Forum a success :) We're also missing your +1 vote to show 
which sessions you'd like to see.





==> Please take 3 minutes to list any idea you want to discuss together 
as developers and users, and +1/-1 sessions to show your interest:



https://etherpad.openstack.org/p/BOS-UC-brainstorming



We will close the etherpad on Tuesday, so time is tight!


Once you've done that, you might like to share your ideas on the mailing 
list ...





PS - If you want to learn more about the forum, check out:
* http://superuser.openstack.org/articles/openstack-forum/
* https://wiki.openstack.org/wiki/Forum




Regards,


Tom

___
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-operators] Forum in Boston - make some noise!

[Tom Fifield]

Hi all,

The end of brainstorming for our first Forum in Boston is fast 
approaching, and we need your help.


We don't have even close to enough topic suggestions on our etherpad to 
make the Forum a success :) We're also missing your +1 vote to show 
which sessions you'd like to see.





==> Please take 3 minutes to list any idea you want to discuss together 
as developers and users, and +1/-1 sessions to show your interest:



https://etherpad.openstack.org/p/BOS-UC-brainstorming



We will close the etherpad on Tuesday, so time is tight!


Once you've done that, you might like to share your ideas on the mailing 
list ...





PS - If you want to learn more about the forum, check out:
* http://superuser.openstack.org/articles/openstack-forum/
* https://wiki.openstack.org/wiki/Forum




Regards,


Tom

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

Re: [Openstack] Trove is skipped in Newton

[Wang Sen]

Hi Amrith,

Thanks for your reply.

I appreciate you very much if I can get help from my colleagues.

I have tried many ways to deploy trove, but all attempts failed to create
database instances.

1. trove-integration installation & devstack installation

Just following the trove installation docs, I deployed trove on ubuntu 14.04
with redstack. Also, I have tried to deploy trove with devstack following the
instructions of the book <>. Both of the two ways failed with
'cannot allocate network' error when creating database instance.

2. openstack Mitaka & Newton installation

https://bugs.launchpad.net/trove/+bug/1658008

3. Tesora EE 1.9

The instance will go to error state because of request timeout error.

On Thu, Mar 09, 2017 at 06:47:18AM -0500, Amrith Kumar wrote:
> Wang Sen, in what environment is this (x86 or non-x86)? I know of at least
> three teams within IBM who have successfully deployed Trove on both x86 and
> non-x86 systems and a number of different releases.
> 
> If you are interested, I'm happy to connect you with several of your fellow
> IBM'ers who may be able to help you with this, or they may see this email
> and reach out to you directly.
> 
> -amrith
> 
> -Original Message-
> From: Wang Sen [mailto:wang...@linux.vnet.ibm.com] 
> Sent: Thursday, March 9, 2017 2:32 AM
> To: Mark Kirkwood 
> Cc: openstack@lists.openstack.org
> Subject: Re: [Openstack] Trove is skipped in Newton
> 
> I have been trying to deploy trove since last December, but my database
> instances never escape from BUILD or Error state :(
> 
> On Tue, Mar 07, 2017 at 09:15:25PM +1300, Mark Kirkwood wrote:
> > I haven't tried to get Trove working with latest versions - but 
> > experience with previous (Kilo, Liberty, Mitaka) ones suggests that 
> > the creation of guest images requires painstaking determination and 
> > error checking - as the supplied docs are - somewhat - lacking...(read 
> > between the lines here).
> > 
> > Best wishes
> > 
> > 
> > Mark
> > 
> > On 07/03/17 20:13, Evgeniy Ivanov wrote:
> > >Hello everybody,
> > >
> > >I found some interesting info about Trove in Newton. I'm able to 
> > >deploy successfully some trove components (api, conductor and
> > >taskmanager) on my test Newton environment. As for the Trove 
> > >guestagent - I'm totally not able to run it neither on Ubuntu Trusty 
> > >nor Ubuntu Xenial.
> > >
> > >I found there are no Newton packages for Trusty in The Ubuntu Cloud 
> > >Archive. The last supported release is Mitaka (I checked the 
> > >RELEASE_MAP). That looks there is no support for Newton in Trusty, 
> > >therefore I can not use Trove in Newton.
> > >
> > >As for the Xenial release, here is a bug where Amrith Kumar (CTO
> > >Tesora) says there is no support for Newton also -
> > >https://bugs.launchpad.net/trove/+bug/1652312 (Should be in Ocata
> > >only)
> > >
> > >For me, it looks like Tesora just skipped Newton, did they?
> > >
> > >I'm asking here because there is no way to get any answers from 
> > >Tesora and Co.
> > >
> > >Thanks for any help!
> > >
> > 
> > 
> > ___
> > 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-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

[Ghanshyam Mann]

On Fri, Mar 10, 2017 at 7:23 AM, Lance Bragstad  wrote:

>
>
> On Thu, Mar 9, 2017 at 3:46 PM, Doug Hellmann 
> wrote:
>
>> Excerpts from Andrea Frittoli's message of 2017-03-09 20:53:54 +:
>> > Hi folks,
>> >
>> > I'm trying to figure out what's the best approach to fade out testing of
>> > deprecated API versions.
>> > We currently host in Tempest API tests for Glance API v1, Keystone API
>> v2
>> > and Cinder API v1.
>> >
>> > According to the guidelines for the "follow-standard-deprecation" tag
>> [0],
>> > when projects that have that tag deprecate a feature:
>> >
>> > "Code will be frozen and only receive minimal maintenance (just so that
>> it
>> > continues to work as-is)."
>> >
>> > I interpret this so that projects should maintain some level of testing
>> of
>> > the deprecated feature, including a deprecated API version.
>> > The QA team does not see value in testing deprecated API versions in the
>> > common gate jobs, so my question is what do to with those tests.
>> >
>> > One option is to maintain them in Tempest until the API version is
>> removed,
>> > and run them in dedicated project jobs.
>> > This means that tempest would have to run those jobs as well, so three
>> > extra jobs, until the API version is removed.
>> >
>> > The other option is to move those tests out of Tempest, into the
>> projects.
>> > This would imply back porting them to all relevant branches as well,
>> but it
>> > would have the advantage of decoupling them from Tempest. It should be
>> no
>> > concern from an API stability POV since the code for that API will be
>> > frozen.
>> > Tests for deprecated APIs in cinder, keystone and glance are all - as
>> far
>> > as I can tell - removed or deprecated from interoperability guidelines,
>> so
>> > moving the tests out of Tempest would not be an issue in that sense.
>> >
>> > The 2nd option involves a bit more initial overhead for the removal of
>> > tests, but I think it would works for the best on the long term.
>> >
>> > There is a 3rd option as well, which is to stop running integration
>> testing
>> > on deprecated API versions before they are actually removed, but I feel
>> > that would not meet the criteria defined by the
>> follow-standard-deprecation
>> > tag.
>> >
>> > Thoughts?
>> >
>> > andrea
>>
>> Are any of those tests used by the interoperability working group
>> (formerly DefCore)?
>>
>>
> That's a good question. I was very curious about this because last I
> checked keystone had v2.0 calls required for defcore. Looks like that might
> not be the case anymore [0]? I started a similar thread to this after the
> PTG since that was something our group talked about extensively during the
> deprecation session [1].
>
> ​Yes, it seems no Volume v1 and Keystone v2 tests usage in defcore
2017.01.json [0]​. But there are some compute tests which internally use
glance v1 API call [2]. But on mentioned flagged action- Nova already moved
to v2 APIs and tempest part is pending which can be fixed to make call on
v2 APIs only (which can be part of this work and quick).

​From options about deprecated APIs testing, I am with options 2 which
really take out the load of Tempest tests maintenance and gate.   ​

​But another question is about stable branch testing of those API, like
glance v1 and identity v2 APIs are supported (not deprecated) in Mitaka.
​As Tempest is responsible of testing all stable branch behavior too, Should
 we keep testing them till all Mitaka EOL (till APIs are in deprecated
state in all stable branch) ?​




>
> [0] https://github.com/openstack/defcore/blob/master/2017.01.json
> [1] http://lists.openstack.org/pipermail/openstack-dev/
> 2017-March/113166.html
>
> ​[2]
https://git.openstack.org/cgit/openstack/defcore/tree/2017.01.json#n294  ​

>
>
>> Doug
>>
>> >
>> > [0]
>> > https://governance.openstack.org/tc/reference/tags/assert_fo
>> llows-standard-deprecation.html
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [oslo] question about oslo_utils and oslo_versonedobjects

[zengchen]

Hi jay:
Understand you. It is a good method!
I will try to update my codes.


Really appreciate your reply. Thanks!


Best Wishes!
zeng chen



At 2017-03-10 02:52:55, "Jay Pipes"  wrote:
>On 03/09/2017 01:37 AM, zengchen wrote:
>> I'm contributing on Karbor (https://wiki.openstack.org/wiki/Karbor).
>> Recently, I find a bug in the following codes.
>>
>> def resume_operation(self, operation_id, **kwargs):
>> end_time = kwargs.get('end_time_for_run')
>> now = datetime.utcnow()
>
>Instead of datetime.utcnow(), do:
>
>  from oslo_utils import timeutils
>  ...
>
>  now = timeutils.utcnow(with_timezone=True)
>
>Alternately, you might consider creating a closure that masks the 
>with_timezone=True parameter. For instance, you could have a 
>karbor.utils file that contains something like this:
>
>  import functools
>
>  from oslo_utils import timeutils
>
>
>  utcnow = functools.partial(timeutils.utcnow, with_timezone=True)
>
>and then in the file that has your resume_operation() method, you would 
>instead:
>
>  from karbor import utils
>  ...
>
>  now = utils.utcnow()
>
>Best,
>-jay
>
>> if not isinstance(end_time, datetime) or now > end_time:
>> return
>>
>> 'end_time_for_run' comes from DB with following definition.
>> class ScheduledOperationState():
>> fields = {
>> 'end_time_for_run': fields.DateTimeField(nullable=True),
>> }
>> when 'now' compares to 'end_time', it will raise an exception as I
>> described before.
>>
>> I mean now that timeutils.untcnow and datetime.utcnow will return a time
>> without
>> a timezone info attached by default, why not  change DateTimeField to
>> keep it
>> coincidence with them. I should be a good optimize in the point of view
>> of easy of use.
>> Certainly, I can change the codes as you described.
>>
>> Really appreciate your reply.
>>
>> Best Wishes!
>> zeng chen
>>
>>
>>
>> At 2017-03-09 10:43:23, "Jay Pipes"  wrote:
>>>On 03/08/2017 09:07 PM, zengchen wrote:
 Hi, jay
 Thanks for your reply. Do you means it is no need to do that optimization?
 In my opinion, It is better if do some change. Thanks again.
>>>
>>>I'm not quite following you. I don't believe there's any need to change
>>>anything nor any need to optimize anything.
>>>
>>>Can you elaborate on what issue you are facing?
>>>
>>>Best,
>>>-jay
>>>
 At 2017-03-08 00:57:51, "Jay Pipes"  wrote:
>On 03/07/2017 01:34 AM, zengchen wrote:
>> Hi, guys:
>>  I find a non-coincidence definition in Oslo,
>>
>>  oslo_utils.timeutils.utcnow is defined like this:
>>  def utcnow(with_timezone=False):
>>
>> oslo_versonedobjects.fields.DateTimeField is defined like this
>> classDateTimeField(AutoTypedField): def__init__(self, tzinfo_aware=True,
>> **kwargs):
>>
>> a = utcnow()
>> class ABC(VersionedObject):
>> fields = {
>> created_at = fields.DateTimeField()
>> }
>> b = ABC(), and fill it by db record.
>>
>> If I compare a and b.created_at,  it will raise an exception like 
>> this:
>>'TypeError: can't compare offset-naive and offset-aware datetimes'
>> because a's value is like this:
>> datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
>> b.created_at 's value is like this:
>>  datetime.datetime(2017, 3, 7, 2, 35, 27,
>> 400786,*tzinfo=*)
>>
>>Can these two kinds of time's definition be coincident? For example:
>>def utcnow(with_timezone=*False*):
>>
>>class DateTimeField(AutoTypedField):
>> def __init__(self, tzinfo_aware=*False*, **kwargs):
>
>Hi Zeng,
>
>Yes, you will want to use utcnow(with_timezone=True) and the default
>ovo.fields.DateTimeField definition *or* use utcnow() and a
>ovo.fields.DateTimeField(tzinfo_aware=False) definition.
>
>Best,
>-jay
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 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] Disable Mac and IP spoof protection

[Sterdnot Shaken]

That was it!!! Worked perfectly! Thank you very much Akihiro and Yura!

On Thu, Mar 9, 2017 at 3:25 AM, Akihiro Motoki  wrote:

> 2017-03-09 16:59 GMT+09:00 Yura Poltoratskiy :
> > Hi.
> >
> > We have OpenVZ as an instance, so there are many ip addresses on the
> > instance. The only thing that I've done was disabling PortSecurity.
> >
> > If I'm correct, there is no way to update port for disabling PortSec, one
> > have to delete port and to create a new with
> > "--port-security-enabled=False".
>
> You don't need to delete a port.
> You can set port_security_enabled to False by:
>
> neutron port-update  --port-security-enabled=False
>
> or
>
> openstack port set --disable-port-security 
>
> >
> > 09.03.2017 03:18, Sterdnot Shaken пишет:
> >>
> >> Is there a way to disable Mac and IP spoof protection for just 1
> instance?
> >>
> >>
> >> I want to run an L2TP server on that instance so I can merge a remote
> >> (over the internet) broadcast domain at a customer site with a Openstack
> >> tenant network. To do this though, I need Openstack to allow n number of
> >> MAC addresses and IP's to be allowed out the instances port, which
> >> IP/MAC spoofing is preventing...
> >>
> >>
> >> Any ideas?
> >>
> >>
> >> Thanks in advance!!
> >>
> >>
> >>
> >> ___
> >> 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
>
___
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] [nova] Core team changes

[Matt Riedemann]

I wanted to let everyone know of some various core team changes within Nova.

nova-core
-

I've discussed it with and removed Daniel Berrange (danpb) and Michael 
Still (mikal) from the nova-core team. Both are busy working on other 
projects and have been for awhile now, and I wanted to have the list 
reflect that reality. I'm sure both would have a short on-ramp to get 
back in should the situation change.


nova-specs-core
---

I've also removed Dan and Michael from nova-specs-core for the same reasons.

I've added Jay Pipes (jaypipes) and Sylvain Bauza (bauzas) to the 
nova-specs-core team. This was probably a long time coming. Both are 
very influential in the project and the direction and priorities from 
release to release.


nova-stable-maint
-

During the PTG I added Sylvain to the nova-stable-maint core team. 
Sylvain knows the rules about the stable branch support phases and has a 
keen eye for what's appropriate and what's not for a backport.


--

Thank you to Daniel and Michael for everything they've done for Nova 
over the years and I hope them the best in their current work.  And 
thank you to Jay and Sylvain for the continuing work that you're doing 
to keep moving Nova forward.


--

Thanks,

Matt Riedemann

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

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Zane Bitter]

On 08/03/17 11:23, David Moreau Simard wrote:

The App Catalog, to me, sounds sort of like a weird message that
OpenStack somehow requires applications to be
packaged/installed/deployed differently.
If anything, perhaps we should spend more effort on advertising that
OpenStack provides bare metal or virtual compute resources and that
apps will work just like any other places.


Look, it's true that legacy apps from the 90s will run on any VM you can 
give them. But the rest of the world has spent the last 15 years moving 
on from that. Applications of the future, and increasingly the present, 
span multiple VMs/containers, make use of services provided by the 
cloud, and interact with their own infrastructure. And users absolutely 
will need ways of packaging and deploying them that work with the 
underlying infrastructure. Even those apps from the 90s should be taking 
advantage of things like e.g. Neutron security groups, configuration of 
which is and will always be out of scope for Docker Hub images.


So no, we should NOT spend more effort on advertising that we aim to 
become to cloud what Subversion is to version control. We've done far 
too much of that already IMHO.


regards,
Zane.


David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Wed, Mar 8, 2017 at 9:41 AM, Jay Pipes  wrote:

On 03/06/2017 06:26 AM, Thierry Carrez wrote:


Hello everyone,

The App Catalog was created early 2015 as a marketplace of pre-packaged
applications that you can deploy using Murano. Initially a demo by
Mirantis, it was converted into an open upstream project team, and
deployed as a "beta" as apps.openstack.org.

Since then it grew additional categories (Glance images, Heat & Tosca
templates), but otherwise did not pick up a lot of steam. The website
(still labeled "beta") features 45 glance images, 6 Tosca templates, 13
heat templates and 94 murano packages (~30% of which are just thin
wrappers around Docker containers). Traffic stats show around 100 visits
per week, 75% of which only read the index page.

In parallel, Docker developed a pretty successful containerized
application marketplace (the Docker Hub), with hundreds of thousands of
regularly-updated apps. Keeping the App Catalog around (including its
thinly-wrapped Docker container Murano packages) make us look like we
are unsuccessfully trying to compete with that ecosystem, while
OpenStack is in fact completely complementary.

In the past we have retired projects that were dead upstream. The App
Catalog is not in this case: it has an active maintenance team, which
has been successfully maintaining the framework and accepting
applications. If we end up retiring the App Catalog, it would clearly
not be a reflection on that team performance, which has been stellar
despite limited resources. It would be because the beta was arguably not
successful in building an active marketplace of applications, and
because its continuous existence is not a great fit from a strategy
perspective. Such removal would be a first for our community, but I
think it's now time to consider it.

Before we discuss or decide anything at the TC level, I'd like to
collect everyone thoughts (and questions) on this. Please feel free to
reply to this thread (or reach out to me privately if you prefer). Thanks
!



Mirantis' position is that the App Catalog was a good idea, but we agree
with you that other application repositories like DockerHub and Quay.io are
both more useful and more actively used.

The OpenStack App Catalog does indeed seem to unnecessarily compete with
those application repositories, and we would support its retirement if that
is what the community would like to do. We'll provide resources and help in
winding anything down if needed.

Best,
-jay


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


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




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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

OK, I will work on a plan that migrates the code into Horizon, thanks everyone!

Travis, can the searchlight details page stuff be done through
extending the base resource type in Horizon? If not, is that perhaps a
limitation of the extensible service?


 Richard


On 10 March 2017 at 02:20, McLellan, Steven  wrote:
> I concur; option 4 is the only one makes sense to me and was what was 
> intended originally. As long as we can do it in one fell swoop in one cyclle 
> (preferably sooner than later) there should be no issues.
>
>
>
>
> On 3/9/17, 8:35 AM, "Tripp, Travis S"  wrote:
>
>>Let me get Matt B in on this discussion, but basically, option 4 is my 
>>initial feeling as Rob stated.
>>
>>One downside we saw with this approach is that we weren’t going to be able to 
>>take advantage of searchlight capabilities in details pages if everything was 
>>in native horizon.  Although, I suppose that could be done by using the 
>>hz-if-services directive [0] if horizon will allow searchlight optimized code 
>>to be in the horizon repo.
>>
>>[0] 
>>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>
>>-Travis
>>
>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:
>>
>>I tried searching the meeting logs but couldn’t find where we discussed 
>> this in the Searchlight meeting. The conclusion at the time was option 4 
>> IIRC. The main thing is to make sure we get it done within one cycle, even 
>> if it isn’t default. this means searchlight-ui doesn’t have to carry some 
>> horrible workarounds and can just remove the code from their repo.
>>
>>Basically; start putting the code in the Horizon repo, and when its done, 
>> Searchlight-UI can remove it from their repo.
>>
>>Rob
>>
>>
>>> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
>>>
>>> Hi Searchlight and Horizon folks,
>>>
>>> I'd like to re-use the wonderful resource type code from
>>> searchlight-ui (in particular os-nova-servers right now but
>>> potentially others down the track) and was wondering whether you'd had
>>> any thoughts about how we might share that code? Off the top of my
>>> head I see a few options:
>>>
>>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>>> pretty unlikely to happen (depending on any optional panel means it's
>>> not really optional any longer ;-)
>>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
>> terrible.
>>> 3. We move the code from searchlight-ui into a separate project that
>>> both Horizon and searchlight-ui depend upon; this could be made to
>>> work, though it's Yet Another Project.
>>> 4. We move the code from searchlight-ui into Horizon. I think this is
>>> most likely to work.
>>>
>>> What are your thoughts? Have I missed an option in this list that you
>>> think is a better one? Have I missed the mark in my analysis of the
>>> options I've presented?
>>>
>>>
>>>  Richard
>>>
>>> 
>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>__
>>OpenStack Development Mailing List (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-operators] OpenStack Summit Boston- Schedule Now Live!

[Erin Disney]

Hi everyone,

The main conference schedule for the upcoming OpenStack Summit in BOSTON 
 is now 
available! 

SCHEDULE: https://www.openstack.org/summit/boston-2017/summit-schedule/ 

Hear from these OpenStack users: Gap Inc., Harvard, US Army Cyber School, AT, 
Bloomberg, China Mobile, CERN & more! 

Log in with your OpenStackID  and start building your 
schedule now! It will automatically sync with the mobile app, which will be 
available by mid-April. Please note: iCal and Google calendar integration will 
be available once we finalize the room assignments for all events. 

Register now  at the early 
bird discounted rate & save 50% on your Summit ticket before prices increase on 
March 14 at 11:59pm PDT (March 15 at 7:59 UTC).


IMPORTANT INFORMATION
Hotels: Discounted rates for attendees and booking information are available 
here . Book soon 
to ensure your spot!
Interested in sponsoring the Summit? Sponsorship opportunities are still 
available. Find more information HERE 
. Deadline to sign the 
contract is March 13.
The StackCity community party 

 is returning! Add it to your schedule and stay tuned - registration will be 
open soon! 
Take the Certified OpenStack Administrator exam onsite at the Boston Summit! 
Learn more and register.  

Visas: If you require a Visa Invitation Letter, forms must be submitted before 
April 17. Because of minimum mailing and approval periods, no exceptions can be 
made. Submit your Visa Invitation Letter request here. 
 
Plan your visit with the Boston City Guide 
. From 
restaurants to must see sites––we’ve done the research for you.


SPEAKER NOTIFICATIONS
If you submitted a talk - check your email. Everyone who submitted a speaking 
proposal for the Summit will receive an email notification to let them know 
whether or not their talk has been accepted. The email sent to selected 
speakers was sent from speakersupp...@openstack.org 
 and contains important next steps and 
speaker registration codes. Each speaker is responsible for registering 
themselves to attend the Summit; please make sure your colleagues read the 
email and complete this step.

Contact sum...@openstack.org with any questions.

See you in Boston!

Cheers,
Erin


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

[openstack-dev] OpenStack Summit Boston- Schedule Now Live!

[Erin Disney]

Hi everyone,

The main conference schedule for the upcoming OpenStack Summit in BOSTON 
 is now 
available! 

SCHEDULE: https://www.openstack.org/summit/boston-2017/summit-schedule/ 

Hear from these OpenStack users: Gap Inc., Harvard, US Army Cyber School, AT, 
Bloomberg, China Mobile, CERN & more! 

Log in with your OpenStackID  and start building your 
schedule now! It will automatically sync with the mobile app, which will be 
available by mid-April. Please note: iCal and Google calendar integration will 
be available once we finalize the room assignments for all events. 

Register now  at the early 
bird discounted rate & save 50% on your Summit ticket before prices increase on 
March 14 at 11:59pm PDT (March 15 at 7:59 UTC).


IMPORTANT INFORMATION
Hotels: Discounted rates for attendees and booking information are available 
here . Book soon 
to ensure your spot!
Interested in sponsoring the Summit? Sponsorship opportunities are still 
available. Find more information HERE 
. Deadline to sign the 
contract is March 13.
The StackCity community party 

 is returning! Add it to your schedule and stay tuned - registration will be 
open soon! 
Take the Certified OpenStack Administrator exam onsite at the Boston Summit! 
Learn more and register.  

Visas: If you require a Visa Invitation Letter, forms must be submitted before 
April 17. Because of minimum mailing and approval periods, no exceptions can be 
made. Submit your Visa Invitation Letter request here. 
 
Plan your visit with the Boston City Guide 
. From 
restaurants to must see sites––we’ve done the research for you.


SPEAKER NOTIFICATIONS
If you submitted a talk - check your email. Everyone who submitted a speaking 
proposal for the Summit will receive an email notification to let them know 
whether or not their talk has been accepted. The email sent to selected 
speakers was sent from speakersupp...@openstack.org 
 and contains important next steps and 
speaker registration codes. Each speaker is responsible for registering 
themselves to attend the Summit; please make sure your colleagues read the 
email and complete this step.

Contact sum...@openstack.org with any questions.

See you in Boston!

Cheers,
Erin


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

Re: [openstack-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

[Lance Bragstad]

On Thu, Mar 9, 2017 at 3:46 PM, Doug Hellmann  wrote:

> Excerpts from Andrea Frittoli's message of 2017-03-09 20:53:54 +:
> > Hi folks,
> >
> > I'm trying to figure out what's the best approach to fade out testing of
> > deprecated API versions.
> > We currently host in Tempest API tests for Glance API v1, Keystone API v2
> > and Cinder API v1.
> >
> > According to the guidelines for the "follow-standard-deprecation" tag
> [0],
> > when projects that have that tag deprecate a feature:
> >
> > "Code will be frozen and only receive minimal maintenance (just so that
> it
> > continues to work as-is)."
> >
> > I interpret this so that projects should maintain some level of testing
> of
> > the deprecated feature, including a deprecated API version.
> > The QA team does not see value in testing deprecated API versions in the
> > common gate jobs, so my question is what do to with those tests.
> >
> > One option is to maintain them in Tempest until the API version is
> removed,
> > and run them in dedicated project jobs.
> > This means that tempest would have to run those jobs as well, so three
> > extra jobs, until the API version is removed.
> >
> > The other option is to move those tests out of Tempest, into the
> projects.
> > This would imply back porting them to all relevant branches as well, but
> it
> > would have the advantage of decoupling them from Tempest. It should be no
> > concern from an API stability POV since the code for that API will be
> > frozen.
> > Tests for deprecated APIs in cinder, keystone and glance are all - as far
> > as I can tell - removed or deprecated from interoperability guidelines,
> so
> > moving the tests out of Tempest would not be an issue in that sense.
> >
> > The 2nd option involves a bit more initial overhead for the removal of
> > tests, but I think it would works for the best on the long term.
> >
> > There is a 3rd option as well, which is to stop running integration
> testing
> > on deprecated API versions before they are actually removed, but I feel
> > that would not meet the criteria defined by the
> follow-standard-deprecation
> > tag.
> >
> > Thoughts?
> >
> > andrea
>
> Are any of those tests used by the interoperability working group
> (formerly DefCore)?
>
>
That's a good question. I was very curious about this because last I
checked keystone had v2.0 calls required for defcore. Looks like that might
not be the case anymore [0]? I started a similar thread to this after the
PTG since that was something our group talked about extensively during the
deprecation session [1].


[0] https://github.com/openstack/defcore/blob/master/2017.01.json
[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-March/113166.html



> Doug
>
> >
> > [0]
> > https://governance.openstack.org/tc/reference/tags/assert_fo
> llows-standard-deprecation.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (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] [Fault_Genes] Weekly Summary

[Nematollah Bidokhti]

Below is the link to our meeting summary and action items.

https://etherpad.openstack.org/p/Fault-Genes


Thanks,

Nemat Bidokhti

Chief Architect, Cloud Resiliency
IT Product Line, Computing Lab

Futurewei Technologies, Inc.
Huawei R USA
Tel:+1-408-330-4714
Cell:  +1-408-528-4909
Fax:   +1-408-330-5088
E-mail: http://nematollah.bidok...@huawei.com
2330 Central Expressway
Santa Clara, CA 95050
http://www.huawei.com/
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Evan Bollig PhD]

Hey Boris,

Which mapping? Hope you were looking for the shibboleth user
mapping. Also, hope this is the right way to share the paste (first
time using this):
http://paste.openstack.org/show/3snCb31GRZfAuQxdRouy/

Cheers,
-E
--
Evan F. Bollig, PhD
Scientific Computing Consultant, Application Developer | Scientific
Computing Solutions (SCS)
Minnesota Supercomputing Institute | msi.umn.edu
University of Minnesota | umn.edu
boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556


On Thu, Mar 9, 2017 at 7:50 AM, Boris Bobrov  wrote:
> Hi,
>
> Please paste your mapping to paste.openstack.org
>
> On 03/09/2017 02:07 AM, Evan Bollig PhD wrote:
>> I am on Ocata with Shibboleth auth enabled. I noticed that Federated
>> users with the admin role no longer have authorization to use the
>> Admin** panels in Horizon related to Nova, Cinder and Neutron. All
>> regular Identity and Project tabs function, and there are no problems
>> with authorization for local admin users.
>>
>> -
>> These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
>> Defaults, Metadata, System Information
>>
>> These result in logout: Instances, Volumes, Networks, Routers, Floating IPs
>>
>> This is not present: Overview
>> -
>>
>> The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
>> openstack-dashboard-11.0.0-1.el7.noarch
>> python-django-horizon-11.0.0-1.el7.noarch
>> python2-keystonemiddleware-4.14.0-1.el7.noarch
>> python2-keystoneclient-3.10.0-1.el7.noarch
>> openstack-keystone-11.0.0-1.el7.noarch
>> python2-keystoneauth1-2.18.0-1.el7.noarch
>> python-keystone-11.0.0-1.el7.noarch
>>
>> The errors I see in logs are similar to:
>>
>> ==> /var/log/horizon/horizon.log <==
>> 2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
>> Traceback (most recent call last):
>>   File 
>> "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
>> line 53, in get_tenant_list
>> tenants, has_more = api.keystone.tenant_list(request)
>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>> line 351, in tenant_list
>> manager = VERSIONS.get_project_manager(request, admin=admin)
>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>> line 61, in get_project_manager
>> manager = keystoneclient(*args, **kwargs).projects
>>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
>> line 170, in keystoneclient
>> raise exceptions.NotAuthorized
>> NotAuthorized
>>
>> Cheers,
>> -E
>> --
>> Evan F. Bollig, PhD
>> Scientific Computing Consultant, Application Developer | Scientific
>> Computing Solutions (SCS)
>> Minnesota Supercomputing Institute | msi.umn.edu
>> University of Minnesota | umn.edu
>> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
>>
>> __
>> OpenStack Development Mailing List (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] [puppet][tripleo][release] puppet module versioning

[Doug Hellmann]

Excerpts from Alex Schultz's message of 2017-03-09 11:29:28 -0700:
> On Thu, Mar 9, 2017 at 10:54 AM, Doug Hellmann  wrote:
> > Excerpts from Alex Schultz's message of 2017-03-07 12:56:17 -0700:
> >> Ahoy folks,
> >>
> >> I would like to bring attention to deriving version numbers for puppet
> >> modules (for packaging) as part of the release process.  Today we
> >> uncovered an issue[0] in the way that version numbers were being
> >> derived for packages which ultimately broke the TripleO CI upgrade
> >> jobs because the master version was older than the last released Ocata
> >> version.
> >>
> >> As for a bit of history around the puppet version numbers, PEP-440 is
> >> not supported in puppet and they are using a form of SemVer[1] .  So
> >> we've historically chosen to just use X.Y.Z for our version numbers
> >> and we usually end up bumping them prior to cutting a new release.
> >> That being said, for the first time we've run into the issue where the
> >> master branches metadata.json contained a version less than the
> >> stable/ocata branch which resulted in the upgrade jobs failing.
> >>
> >> In this case, we could have avoided the version issue by pushing a
> >> version bump to master after cutting the stable/ocata branch to ensure
> >> that master would be the next version.  We've talked about improving
> >> the automation around the puppet versions in the past and I'm
> >> wondering if this is something that would be best to be done in the
> >> release process.  Now because puppet supports SemVer, we could
> >> designate the next version as a X.Y.Z-dev version in the metadata.json
> >> and would expect packagers to use the metadata.json file as the source
> >> of truth for deriving version information and not using something like
> >> pbr or git describe.  Right now as it sits for puppet modules, we
> >> generally aren't touching the version information until we're ready to
> >> release the next version which doesn't seem right for knowing what the
> >> current version of the code actually is.
> >>
> >> So what I'm proposing is to use a "-dev" pre-release identifier
> >> between version releases for puppet modules.  As part of the tagging
> >> process we could propose the next release version with "-dev" to the
> >> repository.  The flow would look something like...
> >>
> >> MASTER
> >> 1.0.0-dev
> >>+
> >>| TAG: M1
> >>+---> 1.0.0
> >>|
> >>v
> >> MASTER
> >> 1.1.0-dev
> >>+
> >>| TAG: M2
> >>+---> 1.1.0
> >>|
> >>v
> >> MASTER
> >> 1.2.0-dev
> >>+
> >>| TAG: M3
> >>+---> 1.2.0
> >>|
> >>v
> >> MASTER
> >> 1.3.0-dev
> >>+
> >>| TAG: RC1
> >>+---> 1.3.0
> >>|
> >>v
> >> RELEASE
> >>+
> >>| STABLE BRANCH
> >>+---> 1.4.0-dev
> >>|
> >>v
> >> MASTER
> >> 2.0.0-dev
> >>
> >> Currently since the metadata.json file is in the repository and for
> >> the release process we're providing a git hash for the version to tag,
> >> I'm not sure how the dropping of the "-dev" would work.  Since we
> >> basically want the release process to take the hash, mangle the
> >> metadata.json, commit it and use this new hash as the point to tag.
> >> thoughts?
> >
> > The release scripts don't have permission to merge a commit, so it would
> > work better if that step was done manually and then the resulting SHA
> > can be used in the tag request.
> >
> 
> Ok then I guess as part of release prep we can just handle the
> dropping of the -dev.  Would it be possible for the release process to
> at least propose the next '-dev' version via the release tools?

That seems like a reasonable thing to add.  The natural way to do
it is to add a new job to the tag pipeline for the repositories.
You'll likely want to copy some of the configuration from the
tag-releases job, because that runs on a node with permission to
propose new patches.

> > FWIW, we used to do something very similar to this for Python projects,
> > and ended up dropping it because it causes extra synchronization pains
> > around releases. A big part of scaling up release support was making
> > them easier by dropping any references to version numbers in files that
> > have to be checked in. I'm guessing there's no way to do that for
> > puppet?
> >
> 
> No because the metadata.json is the source of truth for the version
> information for the puppet modules so it either has to either exist or
> be generated and committed so that when people checkout from git
> puppet knows what versions are there.  Technically if you're only

Yes, that's what I was afraid of.

> doing source deployments you could manage the versions yourself and
> just ignore the warnings from puppet but it also makes it hard to know
> what your environment has version why.  'puppet module list' pulls the
> version information out of the metadata.json.  If we automate (and
> document) some of this workflow it's not so bad as we've been handling
> all 

Re: [openstack-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

[Doug Hellmann]

Excerpts from Andrea Frittoli's message of 2017-03-09 20:53:54 +:
> Hi folks,
> 
> I'm trying to figure out what's the best approach to fade out testing of
> deprecated API versions.
> We currently host in Tempest API tests for Glance API v1, Keystone API v2
> and Cinder API v1.
> 
> According to the guidelines for the "follow-standard-deprecation" tag [0],
> when projects that have that tag deprecate a feature:
> 
> "Code will be frozen and only receive minimal maintenance (just so that it
> continues to work as-is)."
> 
> I interpret this so that projects should maintain some level of testing of
> the deprecated feature, including a deprecated API version.
> The QA team does not see value in testing deprecated API versions in the
> common gate jobs, so my question is what do to with those tests.
> 
> One option is to maintain them in Tempest until the API version is removed,
> and run them in dedicated project jobs.
> This means that tempest would have to run those jobs as well, so three
> extra jobs, until the API version is removed.
> 
> The other option is to move those tests out of Tempest, into the projects.
> This would imply back porting them to all relevant branches as well, but it
> would have the advantage of decoupling them from Tempest. It should be no
> concern from an API stability POV since the code for that API will be
> frozen.
> Tests for deprecated APIs in cinder, keystone and glance are all - as far
> as I can tell - removed or deprecated from interoperability guidelines, so
> moving the tests out of Tempest would not be an issue in that sense.
> 
> The 2nd option involves a bit more initial overhead for the removal of
> tests, but I think it would works for the best on the long term.
> 
> There is a 3rd option as well, which is to stop running integration testing
> on deprecated API versions before they are actually removed, but I feel
> that would not meet the criteria defined by the follow-standard-deprecation
> tag.
> 
> Thoughts?
> 
> andrea

Are any of those tests used by the interoperability working group
(formerly DefCore)?

Doug

> 
> [0]
> https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html

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

[Openstack-operators] [openstack-operators] Milano Ops Midcycle - Security

[Nick Jones]

Here’s the Etherpad for the Security session at the Ops Midcycle:

https://etherpad.openstack.org/p/MIL-ops-security 


I’ve seeded it with an outline and a couple of suggested topics, mostly based 
on what wasn’t covered in Barcelona.  If there’s anything in particular that 
you think warrants community discussion then please feel free to add a point or 
two - even if you’re not attending!

Thanks all.

-- 

-Nick


-- 
DataCentred Limited registered in England and Wales no. 05611763
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

[Andrea Frittoli]

Hi folks,

I'm trying to figure out what's the best approach to fade out testing of
deprecated API versions.
We currently host in Tempest API tests for Glance API v1, Keystone API v2
and Cinder API v1.

According to the guidelines for the "follow-standard-deprecation" tag [0],
when projects that have that tag deprecate a feature:

"Code will be frozen and only receive minimal maintenance (just so that it
continues to work as-is)."

I interpret this so that projects should maintain some level of testing of
the deprecated feature, including a deprecated API version.
The QA team does not see value in testing deprecated API versions in the
common gate jobs, so my question is what do to with those tests.

One option is to maintain them in Tempest until the API version is removed,
and run them in dedicated project jobs.
This means that tempest would have to run those jobs as well, so three
extra jobs, until the API version is removed.

The other option is to move those tests out of Tempest, into the projects.
This would imply back porting them to all relevant branches as well, but it
would have the advantage of decoupling them from Tempest. It should be no
concern from an API stability POV since the code for that API will be
frozen.
Tests for deprecated APIs in cinder, keystone and glance are all - as far
as I can tell - removed or deprecated from interoperability guidelines, so
moving the tests out of Tempest would not be an issue in that sense.

The 2nd option involves a bit more initial overhead for the removal of
tests, but I think it would works for the best on the long term.

There is a 3rd option as well, which is to stop running integration testing
on deprecated API versions before they are actually removed, but I feel
that would not meet the criteria defined by the follow-standard-deprecation
tag.

Thoughts?

andrea

[0]
https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Hitachi Data Systems drivers

[Sean McGinnis]

On Thu, Mar 09, 2017 at 12:47:17PM -0300, José Eduardo de Carvalho Mello Junior 
wrote:
> 
> Effective, Mar 9, 2017, Hitachi Data Systems will offer its drivers for
> download exclusively via https://support.hds.com. Should you need
> assistance with drivers, please contact
> https://community.hds.com/community/developer-network/open-source/openstack.
> 

Hi José,

Does this mean the Hitachi Cinder drivers will be removed from tree?

Thanks,
Sean

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

Re: [openstack-dev] [infra][tripleo] initial discussion for a new periodic pipeline

[Wesley Hayutin]

On Wed, Mar 8, 2017 at 1:29 PM, Jeremy Stanley  wrote:

> On 2017-03-07 10:12:58 -0500 (-0500), Wesley Hayutin wrote:
> > The TripleO team would like to initiate a conversation about the
> > possibility of creating a new pipeline in Openstack Infra to allow
> > a set of jobs to run periodically every four hours
> [...]
>
> The request doesn't strike me as contentious/controversial. Why not
> just propose your addition to the zuul/layout.yaml file in the
> openstack-infra/project-config repo and hash out any resulting
> concerns via code review?
> --
> Jeremy Stanley
>
>
Sounds good to me.
We thought it would be nice to walk through it in an email first :)

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] [all] Small steps for Go

[Clint Byrum]

Excerpts from Michał Jastrzębski's message of 2017-03-09 11:23:17 -0800:
> Clint, I think it's good to find initial idea to work towards to
> create stuff like infrastructure (testing and such) around golang,
> code guidance, standards and so on. It takes first project to create
> all that stuff and it's good if it's bigger community effort. Next
> projects could just follow these standards really.
> 

I'm not sure I follow. There's already demand for golang infrastructure in
Designate and Swift, so I don't see why we wouldn't make sure our
infrastructure supports those.

> As for Kolla using golang - Kolla uses ansible and k8s today;) Or
> rather Kolla-ansible and Kolla-k8s uses Kolla. If you want to make
> Kolla-golang, you can...it just doesn't make any sense really (imho);)
> 

The etherpad made a veiled reference to Kolla wanting to do something in
Go. I was just making the point that I think deployment projects are
already other-language-based and so don't follow the same set of
constraints as the OpenStack project itself.

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

[openstack-dev] [glance] priorities for the coming week (03/10-03/16)

[Brian Rosmaita]

Hello Glancers,

As discussed at today's Glance weekly meeting, here are the review
priorities for this week:

1. image import refactor
Erno has posted a number of patches related to the backend implementation:
- https://review.openstack.org/443636
- https://review.openstack.org/391441
- https://review.openstack.org/443632
- https://review.openstack.org/391442
- https://review.openstack.org/443633
Please review and leave comments, even on the ones marked "WIP", as Erno
could use the feedback.


2. Hemanth has the first draft of the dev docs for writing E-M-C
database migrations posted:
- https://review.openstack.org/#/c/443741/
It's extremely important to the Glance project that this be clearly and
accurately documented.  Thus, if you *haven't* been involved in the
zero-downtime database migration effort yet, your reviews will be
especially appreciated, as you'll be more likely to spot unstated
assumptions.


Other info:
- spec proposal freeze: 13:59 UTC on Thursday 30 March 2017
- Boston "Forum" planning - add proposals for discussion topics:
  https://etherpad.openstack.org/p/BOS-Glance-brainstorming
- March operators' survey proposal - please leave comments before 16:00
UTC Monday 13 March:
  https://etherpad.openstack.org/p/glance-cache-operator-survey



__
OpenStack Development Mailing 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] Small steps for Go

[Michał Jastrzębski]

Clint, I think it's good to find initial idea to work towards to
create stuff like infrastructure (testing and such) around golang,
code guidance, standards and so on. It takes first project to create
all that stuff and it's good if it's bigger community effort. Next
projects could just follow these standards really.

As for Kolla using golang - Kolla uses ansible and k8s today;) Or
rather Kolla-ansible and Kolla-k8s uses Kolla. If you want to make
Kolla-golang, you can...it just doesn't make any sense really (imho);)

On 7 March 2017 at 09:31, Clint Byrum  wrote:
> Excerpts from Hayes, Graham's message of 2017-03-07 14:19:02 +:
>> On 07/03/2017 13:22, Davanum Srinivas wrote:
>> > Folks,
>> >
>> > Anyone interested? https://etherpad.openstack.org/p/go-and-containers
>> >
>> > Thanks,
>> > Dims
>> >
>>
>> The first thing that is required (according to the new guidelines) is
>> for there to be a technical reason we need to use go, and cannot use
>> python. [0]
>>
>> This was the major point thrown at designate when we asked for
>> permission - if there is now a golang project for the sake of
>> a golang project, that would seem at odds with these (brand new)
>> requirements.
>>
>> The only item in the linked etherpad that would fit that requirement
>> is the Go Common Lib, which is a requirement for any project who wants
>> to use go.
>>
>> Do we want to allow projects innovate, or do we just want Golang in
>> OpenStack now? I honestly cannot follow what is going on in this area.
>>
>
> There's a nasty assumption wrapped in that sentence that isn't quite
> fair. We've always wanted projects to innovate, but the choice of common
> language was entirely designed to put people in a box that was easier
> for operators to consume and debug.
>
> I don't see an actual real problem statement that takes operators and
> users into account in that etherpad*. IMO language bindings is a red
> herring, we have REST API's and they're not so bad that they have to
> be wrapped in convenience libs *cough*OaktreeShade*cough*.
>
> I'd really like to see *users* and/or *operators* be the focus of any
> efforts around Golang, or Lisp, or anything else we ship.
>
> Designate felt that the operators were better served by a Golang
> transfer daemon (IIRC). Hummingbird was created by Swift operators to
> deal with their IO concurrency problems. I _like_ those efforts (now
> that I understand them, which was not easy). But the etherpad kind of
> reads to me like "let's make Go things because container things".. maybe
> somebody can explain it to me like I'm 5?
>
>
> * Kolla is a deployment project, and imo, can do Golang the same way
>   openstack-ansible does ansible and puppet does puppet.
>
> __
> OpenStack Development Mailing List (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] [oslo] question about oslo_utils and oslo_versonedobjects

[Jay Pipes]

On 03/09/2017 01:37 AM, zengchen wrote:

I'm contributing on Karbor (https://wiki.openstack.org/wiki/Karbor).
Recently, I find a bug in the following codes.

def resume_operation(self, operation_id, **kwargs):
end_time = kwargs.get('end_time_for_run')
now = datetime.utcnow()


Instead of datetime.utcnow(), do:

 from oslo_utils import timeutils
 ...

 now = timeutils.utcnow(with_timezone=True)

Alternately, you might consider creating a closure that masks the 
with_timezone=True parameter. For instance, you could have a 
karbor.utils file that contains something like this:


 import functools

 from oslo_utils import timeutils


 utcnow = functools.partial(timeutils.utcnow, with_timezone=True)

and then in the file that has your resume_operation() method, you would 
instead:


 from karbor import utils
 ...

 now = utils.utcnow()

Best,
-jay


if not isinstance(end_time, datetime) or now > end_time:
return

'end_time_for_run' comes from DB with following definition.
class ScheduledOperationState():
fields = {
'end_time_for_run': fields.DateTimeField(nullable=True),
}
when 'now' compares to 'end_time', it will raise an exception as I
described before.

I mean now that timeutils.untcnow and datetime.utcnow will return a time
without
a timezone info attached by default, why not  change DateTimeField to
keep it
coincidence with them. I should be a good optimize in the point of view
of easy of use.
Certainly, I can change the codes as you described.

Really appreciate your reply.

Best Wishes!
zeng chen



At 2017-03-09 10:43:23, "Jay Pipes"  wrote:

On 03/08/2017 09:07 PM, zengchen wrote:

Hi, jay
Thanks for your reply. Do you means it is no need to do that optimization?
In my opinion, It is better if do some change. Thanks again.


I'm not quite following you. I don't believe there's any need to change
anything nor any need to optimize anything.

Can you elaborate on what issue you are facing?

Best,
-jay


At 2017-03-08 00:57:51, "Jay Pipes"  wrote:

On 03/07/2017 01:34 AM, zengchen wrote:

Hi, guys:
 I find a non-coincidence definition in Oslo,

 oslo_utils.timeutils.utcnow is defined like this:
 def utcnow(with_timezone=False):

oslo_versonedobjects.fields.DateTimeField is defined like this
classDateTimeField(AutoTypedField): def__init__(self, tzinfo_aware=True,
**kwargs):

a = utcnow()
class ABC(VersionedObject):
fields = {
created_at = fields.DateTimeField()
}
b = ABC(), and fill it by db record.

If I compare a and b.created_at,  it will raise an exception like this:
   'TypeError: can't compare offset-naive and offset-aware datetimes'
because a's value is like this:
datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
b.created_at 's value is like this:
 datetime.datetime(2017, 3, 7, 2, 35, 27,
400786,*tzinfo=*)

   Can these two kinds of time's definition be coincident? For example:
   def utcnow(with_timezone=*False*):

   class DateTimeField(AutoTypedField):
def __init__(self, tzinfo_aware=*False*, **kwargs):


Hi Zeng,

Yes, you will want to use utcnow(with_timezone=True) and the default
ovo.fields.DateTimeField definition *or* use utcnow() and a
ovo.fields.DateTimeField(tzinfo_aware=False) definition.

Best,
-jay

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




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
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] [ironic] [neutron] Should the ironic-neutron meeting start back up for pike?

[Dmitry Tantsur]

On 03/07/2017 08:44 PM, Michael Turek wrote:

Hey all,

So at yesterday's ironic IRC meeting the question of whether or not the ironic
neutron integration meeting should start back up. My understanding is that this
meeting died down as it became more status oriented.

I'm wondering if it'd be worthwhile to kick it off again as 4 of pike's high
priority items are neutron integration focused.

Personally it'd be a meeting I'd attend this cycle but I could understand if
it's more trouble than it's worth.


I feel quite the same. I'd find it useful for me to learn from more 
knowledgeable folks, but I'd like to hear their opinion ;)




Thoughts?

Thanks,
Mike


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



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

Re: [openstack-dev] [ironic] Removal of the ipminative / pyghmi driver

[Dmitry Tantsur]

On 03/09/2017 07:19 PM, Jay Faulkner wrote:

Hi all,

The ipminative driver Is currently an anomaly in ironic’s tree, despite the 
driver being initially deprecated in Newton[1], and   our desire to drop them 
reiterated on the mailing list in December[2], it was has not been removed from 
the tree prior to the Ocata release.

At the PTG the ironic team had a short discussion about the ipminative (aka 
pyghmi) driver — the conclusion was that unless third party CI was run against 
the driver, we would be forced to follow through on the deprecation and remove 
it. Testing in upstream CI, against VirtualBMC, was mostly rejected due to both 
the ipminative driver and virtualbmc using the same python ipmi library 
(pyghmi), and therefore not being a valid test case. Additionally, further 
adding urgency to the removal, several active ironic contributors who have 
tested ipminative drivers in real-world environments have reported them as 
unstable.

The promise of a native python driver to talk to ipmi in ironic is great, but 
without proper testing and stability, keeping it in-tree does more harm to 
ironic users than good — in fact, there’s very little indication to a deployer 
using ironic that the driver may not work stably.

Therefore, I’m giving the mailing list a two week warning — unless volunteers 
come willing to run third party CI against the ipminative drivers in the next 
two weeks, I will be submitting a patch to remove them entirely from the tree. 
The driver could then be moved into ironic-staging-drivers by any interested 
contributors.


Thanks for writing it Jay. Indeed, we spent too much time waiting for someone to 
overtake this driver. I'm very much in favor of removing it, if somebody does 
not step up *right now*.




-
Jay Faulkner
OSIC

Related-bug: https://bugs.launchpad.net/ironic/+bug/1671532

[1] https://docs.openstack.org/releasenotes/ironic/newton.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108666.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing 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] Some information about the Forum at the Summit in Boston

[Dmitry Tantsur]

On 03/09/2017 07:19 PM, Jay Pipes wrote:

On 03/09/2017 01:06 PM, Dmitry Tantsur wrote:

On 03/09/2017 06:57 PM, Clint Byrum wrote:

Excerpts from Ben Swartzlander's message of 2017-03-09 11:23:31 -0500:




Combine that with the lower cost and subsidized travel support program
for the PTG, and you should end up with a more complete gathering of
developers at PTG, and a better interface with users and operators. That
is the theory, and I think it's worth trying to fit one's approach into
that, rather than try to keep doing things the old way and expecting
this new system to work.


Small correction: it does not seem that the PTG was cheaper for people
attending it.


It was substantially cheaper for many folks, actually. The venue chosen and the
city chosen is significantly cheaper than Boston.


I cannot say anything about Boston (I don't plan on going), and I'm definitely 
not saying for everyone, but here are my (rough) numbers from previous summits.


Tokyo
  flight $1000
  hotel $950

Austin
  flight $1100
  hotel $1100

Barcelona
  flight $200
  hotel $900

Atlanta PTG
  flight $1050
  hotel (recommended) $1100
  ticket $100

Overall, Atlanta would be the most expensive for me, if I used the recommended 
hotel. Even more expensive than Tokyo.




Hotel rooms in Boston are *minimum* $350 per night compared with $180 per night
in Atlanta's Sheraton.


Small correction: *real* price of Sheraton was $220. You're referring to the 
"marketing" price, which does not include a lot of what you have to pay. Dunno 
if it's the same for Boston.




Those of us in certain companies were allowed to use Airbnb which cut the
lodging costs down even further (around $80 per night per person compared with
$150 average Airbnb prices per person in Boston).

Add to that the lack of expensive vendor parties and nighttime events
(*somebody* ends up having to pay for those things, after all) and the costs for
attending (and putting on the PTG) were indeed cheaper in my experience.

-jay


It's at least not universally true. You can safely assume
the Forum to require *additional* budget compared to the classic summit.



__

OpenStack Development Mailing List (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] [all] Some information about the Forum at the Summit in Boston

[Duncan Thomas]

On 9 Mar 2017 18:22, "Jay Pipes"  wrote:
>
> On 03/09/2017 01:06 PM, Dmitry Tantsur wrote:
>>
>> On 03/09/2017 06:57 PM, Clint Byrum wrote:
>>>
>>> Excerpts from Ben Swartzlander's message of 2017-03-09 11:23:31 -0500:
>>
>> 
>>>
>>>
>>> Combine that with the lower cost and subsidized travel support program
>>> for the PTG, and you should end up with a more complete gathering of
>>> developers at PTG, and a better interface with users and operators. That
>>> is the theory, and I think it's worth trying to fit one's approach into
>>> that, rather than try to keep doing things the old way and expecting
>>> this new system to work.
>>
>>
>> Small correction: it does not seem that the PTG was cheaper for people
>> attending it.
>
>
> It was substantially cheaper for many folks, actually. The venue chosen
and the city chosen is significantly cheaper than Boston.
>
> Hotel rooms in Boston are *minimum* $350 per night compared with $180 per
night in Atlanta's Sheraton.
>
> Those of us in certain companies were allowed to use Airbnb which cut the
lodging costs down even further (around $80 per night per person compared
with $150 average Airbnb prices per person in Boston).
>
> Add to that the lack of expensive vendor parties and nighttime events
(*somebody* ends up having to pay for those things, after all) and the
costs for attending (and putting on the PTG) were indeed cheaper in my
experience.

Compared to the summit it as cheaper, but compared to the midcycles cinder
used to have it was definitely more expensive
__
OpenStack Development Mailing 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][tripleo][release] puppet module versioning

[Alex Schultz]

On Thu, Mar 9, 2017 at 10:54 AM, Doug Hellmann  wrote:
> Excerpts from Alex Schultz's message of 2017-03-07 12:56:17 -0700:
>> Ahoy folks,
>>
>> I would like to bring attention to deriving version numbers for puppet
>> modules (for packaging) as part of the release process.  Today we
>> uncovered an issue[0] in the way that version numbers were being
>> derived for packages which ultimately broke the TripleO CI upgrade
>> jobs because the master version was older than the last released Ocata
>> version.
>>
>> As for a bit of history around the puppet version numbers, PEP-440 is
>> not supported in puppet and they are using a form of SemVer[1] .  So
>> we've historically chosen to just use X.Y.Z for our version numbers
>> and we usually end up bumping them prior to cutting a new release.
>> That being said, for the first time we've run into the issue where the
>> master branches metadata.json contained a version less than the
>> stable/ocata branch which resulted in the upgrade jobs failing.
>>
>> In this case, we could have avoided the version issue by pushing a
>> version bump to master after cutting the stable/ocata branch to ensure
>> that master would be the next version.  We've talked about improving
>> the automation around the puppet versions in the past and I'm
>> wondering if this is something that would be best to be done in the
>> release process.  Now because puppet supports SemVer, we could
>> designate the next version as a X.Y.Z-dev version in the metadata.json
>> and would expect packagers to use the metadata.json file as the source
>> of truth for deriving version information and not using something like
>> pbr or git describe.  Right now as it sits for puppet modules, we
>> generally aren't touching the version information until we're ready to
>> release the next version which doesn't seem right for knowing what the
>> current version of the code actually is.
>>
>> So what I'm proposing is to use a "-dev" pre-release identifier
>> between version releases for puppet modules.  As part of the tagging
>> process we could propose the next release version with "-dev" to the
>> repository.  The flow would look something like...
>>
>> MASTER
>> 1.0.0-dev
>>+
>>| TAG: M1
>>+---> 1.0.0
>>|
>>v
>> MASTER
>> 1.1.0-dev
>>+
>>| TAG: M2
>>+---> 1.1.0
>>|
>>v
>> MASTER
>> 1.2.0-dev
>>+
>>| TAG: M3
>>+---> 1.2.0
>>|
>>v
>> MASTER
>> 1.3.0-dev
>>+
>>| TAG: RC1
>>+---> 1.3.0
>>|
>>v
>> RELEASE
>>+
>>| STABLE BRANCH
>>+---> 1.4.0-dev
>>|
>>v
>> MASTER
>> 2.0.0-dev
>>
>> Currently since the metadata.json file is in the repository and for
>> the release process we're providing a git hash for the version to tag,
>> I'm not sure how the dropping of the "-dev" would work.  Since we
>> basically want the release process to take the hash, mangle the
>> metadata.json, commit it and use this new hash as the point to tag.
>> thoughts?
>
> The release scripts don't have permission to merge a commit, so it would
> work better if that step was done manually and then the resulting SHA
> can be used in the tag request.
>

Ok then I guess as part of release prep we can just handle the
dropping of the -dev.  Would it be possible for the release process to
at least propose the next '-dev' version via the release tools?

> FWIW, we used to do something very similar to this for Python projects,
> and ended up dropping it because it causes extra synchronization pains
> around releases. A big part of scaling up release support was making
> them easier by dropping any references to version numbers in files that
> have to be checked in. I'm guessing there's no way to do that for
> puppet?
>

No because the metadata.json is the source of truth for the version
information for the puppet modules so it either has to either exist or
be generated and committed so that when people checkout from git
puppet knows what versions are there.  Technically if you're only
doing source deployments you could manage the versions yourself and
just ignore the warnings from puppet but it also makes it hard to know
what your environment has version why.  'puppet module list' pulls the
version information out of the metadata.json.  If we automate (and
document) some of this workflow it's not so bad as we've been handling
all this version mangling already.

for module in $list; do
pushd $module; sed -ie 's/-dev//' metadata.json; git add
metadata.json; git commit -m "release prep"; git review; popd
done

Thanks,
-Alex

> Doug
>
>>
>> Thanks,
>> -Alex
>>
>> [0] https://bugs.launchpad.net/tripleo/+bug/1669462
>> [1] https://github.com/puppetlabs/puppet/blob/master/lib/semver.rb#L10
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [tc][appcat][murano][app-catalog] The future of the App Catalog

[Christopher Aedo]

On Thu, Mar 9, 2017 at 4:08 AM, Thierry Carrez  wrote:
> Christopher Aedo wrote:
>> On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez  wrote:
>>> [...]
>>> In parallel, Docker developed a pretty successful containerized
>>> application marketplace (the Docker Hub), with hundreds of thousands of
>>> regularly-updated apps. Keeping the App Catalog around (including its
>>> thinly-wrapped Docker container Murano packages) make us look like we
>>> are unsuccessfully trying to compete with that ecosystem, while
>>> OpenStack is in fact completely complementary.
>>
>> Without something like Murano "thinly wrapping" docker apps, how would
>> you propose current users of OpenStack clouds deploy docker apps?  Or
>> any other app for that matter?  It seems a little unfair to talk about
>> murano apps this way when no reasonable alternative exists for easily
>> deploying docker apps.  When I look back at the recent history of how
>> we've handled containers (nova-docker, magnum, kubernetes, etc) it
>> does not seem like we're making it easy for the folks who want to
>> deploy a container on their cloud...
>
> I'd say there are two approaches: you can use the container-native
> approach ("docker run" after provisioning some container-enabled host
> using Nova or K8s cluster using Magnum), or you can use the
> OpenStack-native approach (zun create nginx) and have it
> auto-provisioned for you. Those projects have a narrower scope, and
> fully co-opt the container ecosystem without making us appear as trying
> to build our own competitive application packaging/delivery/marketplace
> mechanism.
>
> I just think that adding the Murano abstraction in the middle of it and
> using an AppCatalog-provided Murano-powered generic Docker container
> wrapper is introducing unnecessary options and complexity -- options
> that are strategically hurting us when we talk to those adjacent
> communities...

OK thank you for making it clearer, now I understand where you're
coming from.  I do agree with this sentiment.  I don't have any
experience with zun but it sounds like it's the least-cost way to
deploy a docker at for the environments where it's installed.

I think overall the app catalog was an interesting experiment, but I
don't think it makes sense to continue as-is.  Unless someone comes up
with a compelling new direction, I don't see much point in keeping it
running.  Especially since it sounds like Mirantis is on board (and
the connection to a murano ecosystem was the only thing I saw that
might be interesting).

-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] [all] Some information about the Forum at the Summit in Boston

[Dmitry Tantsur]

On 03/09/2017 05:23 PM, Ben Swartzlander wrote:

I might be the only one who has negative feelings about the PTG/Forum split, but
I suspect the foundation is suppressing negative feedback from myself and other
developers so I'll express my feelings here. If there's anyone else who feels
like me please reply, otherwise I'll assume I'm just an outlier.


Mmmm, yes and no. I do feel that the PTG was a huge success for the Bare metal 
team. I also feel that this split, with all its problems, is still a step forward.


However, I also find some points you raise to be very valid.



The new structure is asking developers to travel 4 times a year (minimum) and
makes it impossible to participate in 2 or more vertical projects.

I know that most of the people working on Manila have pretty limited travel
budgets, and meeting 4 times a year basically guarantees that a good number of
people will be remote at any given meeting. From my perspective if I'm going to
be meeting with people on the phone I'd rather be on the phone myself and have
everyone on equal footing.


As it was already mentioned in this thread, mixing in-person and remove 
attendees is hardly a receipt for success, so yeah.


My initial understanding of the split was that we now send developers to the 
PTGs, and mostly PMs with one-two representatives (co-located with the event) to 
the forum. This seems to contradict the foundation vision, but I still expect it 
to happen according to how I see it :)


In addition to very valid budget concerns, there are also personal ones. 
Traveling 4 times a year is hard. Traveling overseas 4 times a year is even 
harder. Being away from your family a whole week 4 times a year (and then 
recover for few more days) may not be acceptable for some. Explaining US border 
control why you go to the same conference every 3 month may become challenging 
too :)


I don't see any easy solution, except for lowering the expectations about 
developers on the Forum.




I also normally try to participate in Cinder as well as Manila and the new PTG
structures makes that impossible. I decided to try to be positive and to wait
until after the PTG to make up my mind but having attended in Atlanta it was
exactly as bad as I expected in terms of my ability to participate in Cinder.


This is even a bigger issue. We needed to have numerous discussions between us 
in ironic and nova/neutron. The only options we had were:


1. To use Mon or Tue. Apparently, this is not what these days were meant for. 
Also many developers were still out these days, especially on Monday.


2. To sacrifice both teams time on Wed-Fri.

I'd like to suggest a less straightforward split, that will insert a 
cross-project day *between* the two team days. Roughly:


Mon - important general working groups (API WG, release management).
Tue - dedicated team day
Wed - cross-project discussions and more specific working groups.
Thu - dedicated team day
Fri - hackathon/unconference.



I will be in Boston to try to develop a firsthand opinion of the new Forum
format but as of now I'm pretty unhappy with the proposal. For Manila I'm
proposing that the community either meets at PTG and skips conferences or
meetings at conferences and skips PTGs going forward. I'm not going to ask
everyone to travel 4 times a year.


Me too, with my personal preference towards the PTG and several virtual meetups.

Actually, I have only one strong feeling about the Forum. I don't want to go 
there, if it involves more than 3 hours of flight time.




-Ben Swartzlander
Manila PTL








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



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

[openstack-dev] [ironic] Removal of the ipminative / pyghmi driver

[Jay Faulkner]

Hi all,

The ipminative driver Is currently an anomaly in ironic’s tree, despite the 
driver being initially deprecated in Newton[1], and   our desire to drop them 
reiterated on the mailing list in December[2], it was has not been removed from 
the tree prior to the Ocata release.

At the PTG the ironic team had a short discussion about the ipminative (aka 
pyghmi) driver — the conclusion was that unless third party CI was run against 
the driver, we would be forced to follow through on the deprecation and remove 
it. Testing in upstream CI, against VirtualBMC, was mostly rejected due to both 
the ipminative driver and virtualbmc using the same python ipmi library 
(pyghmi), and therefore not being a valid test case. Additionally, further 
adding urgency to the removal, several active ironic contributors who have 
tested ipminative drivers in real-world environments have reported them as 
unstable.

The promise of a native python driver to talk to ipmi in ironic is great, but 
without proper testing and stability, keeping it in-tree does more harm to 
ironic users than good — in fact, there’s very little indication to a deployer 
using ironic that the driver may not work stably.

Therefore, I’m giving the mailing list a two week warning — unless volunteers 
come willing to run third party CI against the ipminative drivers in the next 
two weeks, I will be submitting a patch to remove them entirely from the tree. 
The driver could then be moved into ironic-staging-drivers by any interested 
contributors.

-
Jay Faulkner
OSIC

Related-bug: https://bugs.launchpad.net/ironic/+bug/1671532

[1] https://docs.openstack.org/releasenotes/ironic/newton.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108666.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Jay Pipes]

On 03/09/2017 01:06 PM, Dmitry Tantsur wrote:

On 03/09/2017 06:57 PM, Clint Byrum wrote:

Excerpts from Ben Swartzlander's message of 2017-03-09 11:23:31 -0500:




Combine that with the lower cost and subsidized travel support program
for the PTG, and you should end up with a more complete gathering of
developers at PTG, and a better interface with users and operators. That
is the theory, and I think it's worth trying to fit one's approach into
that, rather than try to keep doing things the old way and expecting
this new system to work.


Small correction: it does not seem that the PTG was cheaper for people
attending it.


It was substantially cheaper for many folks, actually. The venue chosen 
and the city chosen is significantly cheaper than Boston.


Hotel rooms in Boston are *minimum* $350 per night compared with $180 
per night in Atlanta's Sheraton.


Those of us in certain companies were allowed to use Airbnb which cut 
the lodging costs down even further (around $80 per night per person 
compared with $150 average Airbnb prices per person in Boston).


Add to that the lack of expensive vendor parties and nighttime events 
(*somebody* ends up having to pay for those things, after all) and the 
costs for attending (and putting on the PTG) were indeed cheaper in my 
experience.


-jay

> It's at least not universally true. You can safely assume

the Forum to require *additional* budget compared to the classic summit.



__

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




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


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

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Dmitry Tantsur]

On 03/09/2017 06:57 PM, Clint Byrum wrote:

Excerpts from Ben Swartzlander's message of 2017-03-09 11:23:31 -0500:




Combine that with the lower cost and subsidized travel support program
for the PTG, and you should end up with a more complete gathering of
developers at PTG, and a better interface with users and operators. That
is the theory, and I think it's worth trying to fit one's approach into
that, rather than try to keep doing things the old way and expecting
this new system to work.


Small correction: it does not seem that the PTG was cheaper for people attending 
it. It's at least not universally true. You can safely assume the Forum to 
require *additional* budget compared to the classic summit.




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




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

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Clint Byrum]

Excerpts from Ben Swartzlander's message of 2017-03-09 11:23:31 -0500:
> I might be the only one who has negative feelings about the PTG/Forum 
> split, but I suspect the foundation is suppressing negative feedback 
> from myself and other developers so I'll express my feelings here. If 
> there's anyone else who feels like me please reply, otherwise I'll 
> assume I'm just an outlier.
> 
> The new structure is asking developers to travel 4 times a year 
> (minimum) and makes it impossible to participate in 2 or more vertical 
> projects.
> 
> I know that most of the people working on Manila have pretty limited 
> travel budgets, and meeting 4 times a year basically guarantees that a 
> good number of people will be remote at any given meeting. From my 
> perspective if I'm going to be meeting with people on the phone I'd 
> rather be on the phone myself and have everyone on equal footing.
> 
> I also normally try to participate in Cinder as well as Manila and the 
> new PTG structures makes that impossible. I decided to try to be 
> positive and to wait until after the PTG to make up my mind but having 
> attended in Atlanta it was exactly as bad as I expected in terms of my 
> ability to participate in Cinder.
> 
> I will be in Boston to try to develop a firsthand opinion of the new 
> Forum format but as of now I'm pretty unhappy with the proposal. For 
> Manila I'm proposing that the community either meets at PTG and skips 
> conferences or meetings at conferences and skips PTGs going forward. I'm 
> not going to ask everyone to travel 4 times a year.
> 

If we reframe this as "how can I get the most out of this new situation"
instead of "why I don't like it" then I think you might find things to
like, and you might even find that despite the problems, it has a net
positive effect.

For instance, you are upset that you have to travel 4 times a year. But do
you need _every_ developer at the Forum to hear from operators and users?

Wouldn't you rather relieve those developers of that burden? A few of
you will have to go to the Forum, but in so doing, you should be able
to focus on the important aspect of it: USERS. If two Manila devs go to
the Forum, you can literally ignore each other the entire time and get
a massive amount of value. There's no more pressure pulling you apart in
10 directions like there was at the Design Summit.

Combine that with the lower cost and subsidized travel support program
for the PTG, and you should end up with a more complete gathering of
developers at PTG, and a better interface with users and operators. That
is the theory, and I think it's worth trying to fit one's approach into
that, rather than try to keep doing things the old way and expecting
this new system to work.

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

[openstack-dev] [all][api] POST /api-wg/news

[Ed Leafe]

Greetings OpenStack community,

Today's meeting started on a heavyhearted note, as we hoisted our virtual beers 
and gave a toast to Everett Toews, who recently had to step down from his 
API-WG duties due to a job re-assignment. For those who don't know, Everett and 
I started the API-WG a few years ago, but it was Everett who was the main 
driving force behind getting it to where it is today. His influence, energy, 
and personality will be missed.

We then moved on to discuss the revised API stability guidelines document [4] 
which is getting close to being ready, thanks to some excellent input we 
received at the recent PTG. A few more people have expressed that they have 
comments, so we'd like to get as much input from as broad an audience. If you 
have something to add, do it soon!

We then brainstormed ideas for how to increase participation in the group. 
Everett's recent departure brings the number of cores down to 3, and who knows 
what the future holds for us as the OpenStack job market winds keep changing 
direction. One issue that we noted is that most of the work that we set out to 
do when we formed has been largely completed, so there isn't much excitement 
out there for finishing the rest. We agreed to discuss this with the TC to let 
them know the situation, and to see if they had any ideas for future direction.

And as that topic wound down, we got to know knikolla (Kristi Nikolla), who is 
new to the group, but is interested in contributing because of his work on 
openstack/mixmatch [5], which aims to allow different OpenStack deployments to 
communicate with each other. As you can imagine, API inconsistencies make that 
an even harder task! So we look forward to further discussions with knikolla in 
the future.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community. Nothing at 
the moment, but feel free to get in early on the reviews below.

# Guidelines Currently Under Review [3]

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Refactor and re-validate api change guidelines
  https://review.openstack.org/#/c/421846/

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://review.openstack.org/#/c/421846/
[5] https://github.com/openstack/mixmatch

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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][tripleo][release] puppet module versioning

[Doug Hellmann]

Excerpts from Alex Schultz's message of 2017-03-07 12:56:17 -0700:
> Ahoy folks,
> 
> I would like to bring attention to deriving version numbers for puppet
> modules (for packaging) as part of the release process.  Today we
> uncovered an issue[0] in the way that version numbers were being
> derived for packages which ultimately broke the TripleO CI upgrade
> jobs because the master version was older than the last released Ocata
> version.
> 
> As for a bit of history around the puppet version numbers, PEP-440 is
> not supported in puppet and they are using a form of SemVer[1] .  So
> we've historically chosen to just use X.Y.Z for our version numbers
> and we usually end up bumping them prior to cutting a new release.
> That being said, for the first time we've run into the issue where the
> master branches metadata.json contained a version less than the
> stable/ocata branch which resulted in the upgrade jobs failing.
> 
> In this case, we could have avoided the version issue by pushing a
> version bump to master after cutting the stable/ocata branch to ensure
> that master would be the next version.  We've talked about improving
> the automation around the puppet versions in the past and I'm
> wondering if this is something that would be best to be done in the
> release process.  Now because puppet supports SemVer, we could
> designate the next version as a X.Y.Z-dev version in the metadata.json
> and would expect packagers to use the metadata.json file as the source
> of truth for deriving version information and not using something like
> pbr or git describe.  Right now as it sits for puppet modules, we
> generally aren't touching the version information until we're ready to
> release the next version which doesn't seem right for knowing what the
> current version of the code actually is.
> 
> So what I'm proposing is to use a "-dev" pre-release identifier
> between version releases for puppet modules.  As part of the tagging
> process we could propose the next release version with "-dev" to the
> repository.  The flow would look something like...
> 
> MASTER
> 1.0.0-dev
>+
>| TAG: M1
>+---> 1.0.0
>|
>v
> MASTER
> 1.1.0-dev
>+
>| TAG: M2
>+---> 1.1.0
>|
>v
> MASTER
> 1.2.0-dev
>+
>| TAG: M3
>+---> 1.2.0
>|
>v
> MASTER
> 1.3.0-dev
>+
>| TAG: RC1
>+---> 1.3.0
>|
>v
> RELEASE
>+
>| STABLE BRANCH
>+---> 1.4.0-dev
>|
>v
> MASTER
> 2.0.0-dev
> 
> Currently since the metadata.json file is in the repository and for
> the release process we're providing a git hash for the version to tag,
> I'm not sure how the dropping of the "-dev" would work.  Since we
> basically want the release process to take the hash, mangle the
> metadata.json, commit it and use this new hash as the point to tag.
> thoughts?

The release scripts don't have permission to merge a commit, so it would
work better if that step was done manually and then the resulting SHA
can be used in the tag request.

FWIW, we used to do something very similar to this for Python projects,
and ended up dropping it because it causes extra synchronization pains
around releases. A big part of scaling up release support was making
them easier by dropping any references to version numbers in files that
have to be checked in. I'm guessing there's no way to do that for
puppet?

Doug

> 
> Thanks,
> -Alex
> 
> [0] https://bugs.launchpad.net/tripleo/+bug/1669462
> [1] https://github.com/puppetlabs/puppet/blob/master/lib/semver.rb#L10
> 

__
OpenStack Development Mailing 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] Some information about the Forum at the Summit in Boston

[Ben Swartzlander]

On 03/09/2017 12:10 PM, Jonathan Bryce wrote:

Hi Ben,


On Mar 9, 2017, at 10:23 AM, Ben Swartzlander  wrote:

I might be the only one who has negative feelings about the PTG/Forum split, 
but I suspect the foundation is suppressing negative feedback from myself and 
other developers so I'll express my feelings here. If there's anyone else who 
feels like me please reply, otherwise I'll assume I'm just an outlier.


“Suppressing negative feedback” is a pretty strong accusation (and I’m honestly 
not sure how you even imagine we are doing that). I searched through the last 2 
years of mailing list threads and couldn’t find negative feedback from you 
around the PTG. Same for googling around the internet in general. I might have 
missed a place where you had provided this feedback, so feel free to pass it 
along again. Also, if there’s some proof behind the accusation, I would love to 
see it so I can address it with whoever might be doing the suppressing. It’s 
certainly not something I would support anyone in the foundation doing. You can 
send it to me directly off-list if you feel more comfortable providing it that 
way.


I filled out the official PTG feedback survey in Atlanta and I 
completely panned the event in the survey. I don't know if my name was 
attached to that, but it doesn't matter. I wasn't able to attend the 
in-person feedback session because again, it was scheduled on top of 
time we were using to get work on as a Manila team.


All I know is that the announcement after the PTG was that the feedback 
on the event was all pretty good. I conclude from that that either there 
are very few people who feel like me, or that there are more and their 
feedback was ignored. This ML thread is an attempt to give voice to us 
whether it's just a handful or actually a large number.


I'm not going to write a blog entry that says "OpenStack PTG sucked". 
That would be asinine. I think this developers list is small enough that 
we can have a serious and productive discussion about whether the 
current PTG/Forum event split has merits _for the developer community_.



Putting that aside, I appreciate your providing your input. The most consistent 
piece of feedback we received was around scheduling and visibility for 
sessions, so I think that is definitely an area for improvement at the next 
PTG. I heard mixed feedback on whether the ability to participate in multiple 
projects was better or worse than under the previous model, but understanding 
common conflicts ahead of time might give us a chance to schedule in a way that 
makes the multi-project work more possible. Did you participate in both Cinder 
and Manila mid-cycles in addition to the Design Summit sessions previously? 
Trying to understand which types of specific interactions you’re now less able 
to participate in.


Yes in the past I was able to attend all of the Manila and most of the 
Cinder sessions at the Design summit, and I was able to attend the 
Cinder midcycles in person and (since I'm the PTL) I was able to 
schedule the Manila midcycles to not conflict.



I’m also interested in finding ways to support remote participation, but it’s a 
hard problem that has failed more often than it’s worked when we’ve tried it. 
I’m still open to continuing to attempt new methods—we actually brainstormed 
some ideas in Atlanta and if you have any suggestions, let’s experiment the 
next time around.


My feeling on remote participation is that it's something the project 
teams can manage themselves. If we're going to have a "virtual midcycle" 
(which many projects do) then the team can set it up and nothing is 
required from the foundation to facilitate it. Trying to mix the 
in-person interactions of a summit/forum/ptg with remote attendees 
usually just leads to a poor experience for the remote participants. 
When we have in-person events we do our best to include remote people 
who can't attend but IMO that's still inferior to planning a fully 
virtual event that puts everyone on equal footing.



The PTG was actually an idea that was initiated by development teams, and 
something that we tried to organize to make it as productive as possible for 
the teams. The goal of the PTGs is to provide focused time to that help us make 
better software, and there’s really no other benefit that the Foundation gets 
from them. We did have some teams, like Kuryr, who did not participate in 
person at the PTG. I talked to Antoni before and offered to assist with 
whatever we could when they did their VTG, and we will continue to support 
teams whether they participate in future PTGs or not.


I've been part of OpenStack a long time and my perception of history is 
a bit different. I recall a frustration from developers who attended 
design summits that it was hard to attend both the design summit and the 
conference because they were scheduled on top of eachother. What people 
wanted was a way to attend both events -- either 

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Kevin Benton]

Well it was likely using an older version of neutron if that import was
failing. If you run the tests some time ago on that machine you would have
to run 'tox -r' to reclone neutron.

On Mar 9, 2017 08:46, "Vikash Kumar" 
wrote:

> Hi Igor,
>
> I was trying on Ubuntu 14.04 (trusty). This was weird though.
>
> On Thu, Mar 9, 2017 at 4:54 PM, Duarte Cardoso, Igor <
> igor.duarte.card...@intel.com> wrote:
>
>> Hi Vikash,
>>
>>
>>
>> What OS were you trying on before?
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>> *Sent:* Thursday, March 9, 2017 10:08 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>; ke...@benton.pub
>>
>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
>> "import error: vlanmanager"
>>
>>
>>
>> Tried on Ubuntu 16.04, its fine.
>>
>>
>>
>> On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar <
>> vikash.ku...@oneconvergence.com> wrote:
>>
>> Import path looks OK
>> https://github.com/openstack/networking-sfc/blob/master/netw
>> orking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23
>>
>>
>>
>> Are u suggesting something else?
>>
>>
>>
>> On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton  wrote:
>>
>> That location was recently changed in the Neutron side.[1] It sounds like
>> sfc has to be updated.
>>
>>
>>
>> 1. https://github.com/openstack/neutron/commit/4ec456d31501f
>> 09c68b5c23c488878da32dce75e
>>
>>
>>
>> On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar <
>> vikash.ku...@oneconvergence.com> wrote:
>>
>> Hi Igor,
>>
>>This is weird. I just did a fresh clone and executed *"tox" *command.
>> I am getting same error. Am I missing anything here ? There is no private
>> change here.  Below is the link for entire log.
>>
>>  http://paste.openstack.org/show/601870/
>>
>>
>>
>> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
>> igor.duarte.card...@intel.com> wrote:
>>
>> Hi Vikash,
>>
>> Please stick to pastebin for complete logs.
>>
>>
>>
>> Check your migration files:
>>
>>
>>
>> FAILED: Contract HEAD file does not match migration timeline head,
>> expected: 48072cb59133
>>
>>
>>
>> Best regards,
>>
>> Igor.
>>
>>
>>
>> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
>> *Sent:* Tuesday, March 7, 2017 5:03 PM
>> *To:* openstack-dev 
>> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
>> "import error: vlanmanager"
>>
>>
>>
>> Complete log:
>>
>>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
>> py35 installdeps: -r/home/vikash/guess_vk/python
>> -dev/networking-sfc/requirements.txt, -r/home/vikash/guess_vk/python
>> -dev/networking-sfc/test-requirements.txt
>> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
>> py35 installed: /home/vikash/guess_vk/python-d
>> ev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
>> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
>> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==
>> 0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulso
>> up4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2=
>> =0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==
>> 1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13
>> .1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners
>> ==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.
>> 0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.
>> 4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==
>> 1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth
>> 1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,
>> linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.
>> 1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,
>> monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
>> git+https://github.com/openstack/networking-sfc.git@c51052e3
>> 748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e git+
>> https://github.com/openstack/neutron.git@41be555eddb0f99
>> 47fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,ope
>> nstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.
>> 0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,
>> oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==
>> 2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,
>> oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.
>> policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,
>> oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.
>> utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.
>> 10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==
>> 2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,
>> pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,posit
>> ional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,
>> 

Re: [openstack-dev] [mistral] Mistral Custom Actions API Design

[Dougal Matthews]

On 9 March 2017 at 17:19, Dougal Matthews  wrote:

> On 9 March 2017 at 04:35, Ryan Brady  wrote:
>
>> At the PTG and previous discussions in IRC, I mentioned there were two
>> different design ideas I had for the developer experience for custom action
>> development in mistral-lib.  The purpose and intent behind the patch[1] was
>> discussed in person at the PTG and that was helpful for me wrt to scope.  I
>> feel it would be helpful to discuss and decide together the final piece of
>> this patch.  I'd like to get any feedback on either of these two ideas as
>> they will shape how developers integrate with Mistral in the future, impact
>> our OpenStack integration efforts in mistral-extra.  Nothing stops a
>> developer from adopting either style in their custom action libraries, but
>> most will likely want to remain consistent with style present in the
>> upstream code.
>>
>> I have created separate declaration and usage examples in hopes of
>> illustrating some of the similarities and differences.  To me it seems the
>> base class example is more declarative/explicit, but the mixin example is
>> more extensible and dry.  Both examples reflect on backwards compatibility
>> and possible changes to how mistral checks for sync/async actions and how
>> to pass the context (as needed by actions that integrate with OpenStack).
>>
>>
>> base classes declaration: https://gist.github.com/rbrady/ff86c484e8e6e53b
>> a2dc3dfa17b01b09
>>
>> base class usage: https://gist.github.com/rbrady/716a02fb2bd38d822c6df8
>> bd642d3ea6
>>
>
> The base class approach gets my vote for two reasons:
>
> 1. It is the simplest to use and document.
> 2. I don't think we have enough combinations (yet?) to warrant mixins.
>

3. The set_context method on the mixin isn't as clear as passing it to run.
Imagine I am scanning your code, I can see from the run that the context is
passed in. I don't need to look for the base class and look to see if
self.context is used.


>
>
>
>>
>> mixins declaration: https://gist.github.com/rbrady/d30ae640b19df658
>> a17cd93827125678
>>
>> mixins usage: https://gist.github.com/rbrady/248cb52d5c5f94854d8c76
>> eee911ce8e
>>
>>
>> Thanks,
>>
>> Ryan
>>
>> --
>> Ryan Brady
>> Cloud Engineering
>> rbr...@redhat.com
>> 919.890.8925 <(919)%20890-8925>
>>
>>
>> [1] https://review.openstack.org/#/c/411412/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] Mistral Custom Actions API Design

[Dougal Matthews]

On 9 March 2017 at 04:35, Ryan Brady  wrote:

> At the PTG and previous discussions in IRC, I mentioned there were two
> different design ideas I had for the developer experience for custom action
> development in mistral-lib.  The purpose and intent behind the patch[1] was
> discussed in person at the PTG and that was helpful for me wrt to scope.  I
> feel it would be helpful to discuss and decide together the final piece of
> this patch.  I'd like to get any feedback on either of these two ideas as
> they will shape how developers integrate with Mistral in the future, impact
> our OpenStack integration efforts in mistral-extra.  Nothing stops a
> developer from adopting either style in their custom action libraries, but
> most will likely want to remain consistent with style present in the
> upstream code.
>
> I have created separate declaration and usage examples in hopes of
> illustrating some of the similarities and differences.  To me it seems the
> base class example is more declarative/explicit, but the mixin example is
> more extensible and dry.  Both examples reflect on backwards compatibility
> and possible changes to how mistral checks for sync/async actions and how
> to pass the context (as needed by actions that integrate with OpenStack).
>
>
> base classes declaration: https://gist.github.com/rbrady/
> ff86c484e8e6e53ba2dc3dfa17b01b09
>
> base class usage: https://gist.github.com/rbrady/
> 716a02fb2bd38d822c6df8bd642d3ea6
>

The base class approach gets my vote for two reasons:

1. It is the simplest to use and document.
2. I don't think we have enough combinations (yet?) to warrant mixins.



>
> mixins declaration: https://gist.github.com/rbrady/
> d30ae640b19df658a17cd93827125678
>
> mixins usage: https://gist.github.com/rbrady/
> 248cb52d5c5f94854d8c76eee911ce8e
>
>
> Thanks,
>
> Ryan
>
> --
> Ryan Brady
> Cloud Engineering
> rbr...@redhat.com
> 919.890.8925 <(919)%20890-8925>
>
>
> [1] https://review.openstack.org/#/c/411412/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Telles Nobrega]

Sahara suffered the same effect. Our community is small and we won't be
approved to meet 4 times a year.

This time around we gave higher priority to the PTG and most won't be in
Boston. I think that the PTG itself worked nice for us but it did make it
difficult, no to say impossible, to meet other vertical projects.

Bottom line is, for sahara is still early to have a verdict whether it was
good or bad, and I believe experience and time will improve the PTG. I
agree with the problems mentioned but I also think we can wait a little
more time.

Best regards,

On Thu, 9 Mar 2017 at 14:09 Joshua Harlow  wrote:

> Ben Swartzlander wrote:
> > I might be the only one who has negative feelings about the PTG/Forum
> > split, but I suspect the foundation is suppressing negative feedback
> > from myself and other developers so I'll express my feelings here. If
> > there's anyone else who feels like me please reply, otherwise I'll
> > assume I'm just an outlier.
>
> You aren't alone here.
>
> >
> > The new structure is asking developers to travel 4 times a year
> > (minimum) and makes it impossible to participate in 2 or more vertical
> > projects.
> >
> > I know that most of the people working on Manila have pretty limited
> > travel budgets, and meeting 4 times a year basically guarantees that a
> > good number of people will be remote at any given meeting. From my
> > perspective if I'm going to be meeting with people on the phone I'd
> > rather be on the phone myself and have everyone on equal footing.
>
> The funny part is that if you don't go to the PTG then the following is
> what u get.
>
> 'All ATCs who contributed to the Ocata release but were unable to
> attend the PTG will receive a $300 discount on the current ticket
> price for the Boston Summit. '
>
> So if you don't go to the PTGs (or attend virtually) then you get
> penalized on the summits as well, which is like, ummm, ya super awesome,
> lol.
>
> And don't get me started as to why the summits are so expensive;
> especially knowing how much it costs to join the openstack foundation
> (https://www.openstack.org/join/).
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Jonathan Bryce]

Hi Ben,

> On Mar 9, 2017, at 10:23 AM, Ben Swartzlander  wrote:
> 
> I might be the only one who has negative feelings about the PTG/Forum split, 
> but I suspect the foundation is suppressing negative feedback from myself and 
> other developers so I'll express my feelings here. If there's anyone else who 
> feels like me please reply, otherwise I'll assume I'm just an outlier.

“Suppressing negative feedback” is a pretty strong accusation (and I’m honestly 
not sure how you even imagine we are doing that). I searched through the last 2 
years of mailing list threads and couldn’t find negative feedback from you 
around the PTG. Same for googling around the internet in general. I might have 
missed a place where you had provided this feedback, so feel free to pass it 
along again. Also, if there’s some proof behind the accusation, I would love to 
see it so I can address it with whoever might be doing the suppressing. It’s 
certainly not something I would support anyone in the foundation doing. You can 
send it to me directly off-list if you feel more comfortable providing it that 
way.

Putting that aside, I appreciate your providing your input. The most consistent 
piece of feedback we received was around scheduling and visibility for 
sessions, so I think that is definitely an area for improvement at the next 
PTG. I heard mixed feedback on whether the ability to participate in multiple 
projects was better or worse than under the previous model, but understanding 
common conflicts ahead of time might give us a chance to schedule in a way that 
makes the multi-project work more possible. Did you participate in both Cinder 
and Manila mid-cycles in addition to the Design Summit sessions previously? 
Trying to understand which types of specific interactions you’re now less able 
to participate in.

I’m also interested in finding ways to support remote participation, but it’s a 
hard problem that has failed more often than it’s worked when we’ve tried it. 
I’m still open to continuing to attempt new methods—we actually brainstormed 
some ideas in Atlanta and if you have any suggestions, let’s experiment the 
next time around.

The PTG was actually an idea that was initiated by development teams, and 
something that we tried to organize to make it as productive as possible for 
the teams. The goal of the PTGs is to provide focused time to that help us make 
better software, and there’s really no other benefit that the Foundation gets 
from them. We did have some teams, like Kuryr, who did not participate in 
person at the PTG. I talked to Antoni before and offered to assist with 
whatever we could when they did their VTG, and we will continue to support 
teams whether they participate in future PTGs or not.

Thanks for keeping an open mind on the Forum. If you have opinions around what 
will make it more or less successful, please get involved in the planning for 
it. It’s being planned and scheduled in the open with input from the dev and 
user communities. I’ll be looking out for your feedback after Boston. Promise I 
won’t do anything to suppress it, positive or negative. = )

Jonathan


> The new structure is asking developers to travel 4 times a year (minimum) and 
> makes it impossible to participate in 2 or more vertical projects.
> 
> I know that most of the people working on Manila have pretty limited travel 
> budgets, and meeting 4 times a year basically guarantees that a good number 
> of people will be remote at any given meeting. From my perspective if I'm 
> going to be meeting with people on the phone I'd rather be on the phone 
> myself and have everyone on equal footing.
> 
> I also normally try to participate in Cinder as well as Manila and the new 
> PTG structures makes that impossible. I decided to try to be positive and to 
> wait until after the PTG to make up my mind but having attended in Atlanta it 
> was exactly as bad as I expected in terms of my ability to participate in 
> Cinder.
> 
> I will be in Boston to try to develop a firsthand opinion of the new Forum 
> format but as of now I'm pretty unhappy with the proposal. For Manila I'm 
> proposing that the community either meets at PTG and skips conferences or 
> meetings at conferences and skips PTGs going forward. I'm not going to ask 
> everyone to travel 4 times a year.
> 
> -Ben Swartzlander
> Manila PTL
> 
> 
> On 03/07/2017 07:35 AM, Thierry Carrez wrote:
>> Hi everyone,
>> 
>> I recently got more information about the space dedicated to the "Forum"
>> at the OpenStack Summit in Boston. We'll have three different types of
>> spaces available.
>> 
>> 1/ "Forum" proper
>> 
>> There will be 3 medium-sized fishbowl rooms for cross-community
>> discussions. Topics for the discussions in that space will be selected
>> and scheduled by a committee formed of TC and UC members, facilitated by
>> Foundation staff members. In case you missed it, the brainstorming for
>> topics started last week, announced 

Re: [openstack-dev] [all] Some information about the Forum at the Summit in Boston

[Joshua Harlow]

Ben Swartzlander wrote:

I might be the only one who has negative feelings about the PTG/Forum
split, but I suspect the foundation is suppressing negative feedback
from myself and other developers so I'll express my feelings here. If
there's anyone else who feels like me please reply, otherwise I'll
assume I'm just an outlier.


You aren't alone here.



The new structure is asking developers to travel 4 times a year
(minimum) and makes it impossible to participate in 2 or more vertical
projects.

I know that most of the people working on Manila have pretty limited
travel budgets, and meeting 4 times a year basically guarantees that a
good number of people will be remote at any given meeting. From my
perspective if I'm going to be meeting with people on the phone I'd
rather be on the phone myself and have everyone on equal footing.


The funny part is that if you don't go to the PTG then the following is 
what u get.


'All ATCs who contributed to the Ocata release but were unable to
attend the PTG will receive a $300 discount on the current ticket
price for the Boston Summit. '

So if you don't go to the PTGs (or attend virtually) then you get 
penalized on the summits as well, which is like, ummm, ya super awesome, 
lol.


And don't get me started as to why the summits are so expensive; 
especially knowing how much it costs to join the openstack foundation 
(https://www.openstack.org/join/).



__
OpenStack Development Mailing 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] Some information about the Forum at the Summit in Boston

[Julien Danjou]

On Thu, Mar 09 2017, Ben Swartzlander wrote:

Hi Ben,

[…]

> I will be in Boston to try to develop a firsthand opinion of the new Forum
> format but as of now I'm pretty unhappy with the proposal. For Manila I'm
> proposing that the community either meets at PTG and skips conferences or
> meetings at conferences and skips PTGs going forward. I'm not going to ask
> everyone to travel 4 times a year.

I feel the same as you. I advocated against this change for a year now,
but waited like you to see where this would go.

This cycle I preferred to pick Summit over PTG as I think it's harder to
meet users and operators than it is to meet developer – with whom I work
with all years on IRC or mailing-lists.

Cherry on the cake, by doing this I'm not entitled to a free ATC pass to
attend the summit. I would have to spend $300 to attend a conference for
a project I wrote code for during the last 5 years. Sigh.

Our developer community shrunk this last year and I cannot envision the
benefit of spreading it over 4 events a year.

Cheers,
-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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-Infra] [zuul] Feedback requested for tox job definition

[James E. Blair]

Clark Boylan  writes:

> Also reading these job defs and comparing against the zuulv3 spec it
> isn't clear to me what the expected behavior for inheriting pre and post
> playbooks is. Seems like maybe pre is a queue so parent pre roles run
> first and post is a stack so parent post roles run last? If that is
> already written down and I am just missing it sorry for the noise, if it
> isn't written down maybe we can do that?

Yeah, I think it was first written down in my pre-PTG summary message.
I intend on porting over the relevant portions of that text to the Zuul
documentation soon, once we're finished making major changes to the
config format (I have one such change in progress).

The wording I used to explain it was "nesting" -- when you inherit from
a job, your job nests inside the pre and post playbooks of the job from
which you inherit.  This is because the most basic job should do the
earliest pre-tasks (e.g., set up git repos) which other jobs should be
able to rely on.  Likewise, inheriting jobs should be able to rely on
base jobs performing the most general post-tasks (e.g., copy all of the
logs).

-Jim

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

Re: [openstack-dev] [kolla] Proposing duonghq for core

[Martin André]

On Wed, Mar 8, 2017 at 7:41 AM, Michał Jastrzębski  wrote:
> Hello,
>
> I'd like to start voting to include Duong (duonghq) in Kolla and
> Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
> 21st of March).
>
> Consider this my +1 vote.

+1
Martin

> Cheers,
> Michal
>
> __
> OpenStack Development Mailing List (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] [docs] Docs team meeting

[Alexandra Settle]

Hi everyone,

The docs meeting will be on today, Thursday the 9th March at 2100 UTC in 
#openstack-meeting-alt.

For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Thanks,

Alex


__
OpenStack Development Mailing 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] Some information about the Forum at the Summit in Boston

[Jay Faulkner]

> On Mar 9, 2017, at 8:23 AM, Ben Swartzlander  wrote:
> 
> I might be the only one who has negative feelings about the PTG/Forum split, 
> but I suspect the foundation is suppressing negative feedback from myself and 
> other developers so I'll express my feelings here. If there's anyone else who 
> feels like me please reply, otherwise I'll assume I'm just an outlier.
> 
> The new structure is asking developers to travel 4 times a year (minimum) and 
> makes it impossible to participate in 2 or more vertical projects.
> 

+1

There was a built in assumption to the original planning, that most projects 
had a mid-cycle that people travelled to. For ironic, as an example, we 
switched those to virtual because the number of people who could get travel 
approved was very low.

-
Jay Faulkner


> I know that most of the people working on Manila have pretty limited travel 
> budgets, and meeting 4 times a year basically guarantees that a good number 
> of people will be remote at any given meeting. From my perspective if I'm 
> going to be meeting with people on the phone I'd rather be on the phone 
> myself and have everyone on equal footing.
> 
> I also normally try to participate in Cinder as well as Manila and the new 
> PTG structures makes that impossible. I decided to try to be positive and to 
> wait until after the PTG to make up my mind but having attended in Atlanta it 
> was exactly as bad as I expected in terms of my ability to participate in 
> Cinder.
> 
> I will be in Boston to try to develop a firsthand opinion of the new Forum 
> format but as of now I'm pretty unhappy with the proposal. For Manila I'm 
> proposing that the community either meets at PTG and skips conferences or 
> meetings at conferences and skips PTGs going forward. I'm not going to ask 
> everyone to travel 4 times a year.
> 
> -Ben Swartzlander
> Manila PTL
> 
> 
> On 03/07/2017 07:35 AM, Thierry Carrez wrote:
>> Hi everyone,
>> 
>> I recently got more information about the space dedicated to the "Forum"
>> at the OpenStack Summit in Boston. We'll have three different types of
>> spaces available.
>> 
>> 1/ "Forum" proper
>> 
>> There will be 3 medium-sized fishbowl rooms for cross-community
>> discussions. Topics for the discussions in that space will be selected
>> and scheduled by a committee formed of TC and UC members, facilitated by
>> Foundation staff members. In case you missed it, the brainstorming for
>> topics started last week, announced by Emilien in that email:
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113115.html
>> 
>> 2/ "On-boarding" rooms
>> 
>> We'll have two rooms set up in classroom style, dedicated to project
>> teams and workgroups who want to on-board new team members. Those can
>> for example be booked by project teams to run an introduction to their
>> codebase to prospective new contributors, in the hope that they will
>> join their team in the future. Those are not meant to do traditional
>> user-facing "project intro" talks -- there is space in the conference
>> for that. They are meant to provide the next logical step in
>> contributing after Upstream University and being involved on the
>> sidelines. It covers the missing link for prospective contributors
>> between attending Summit and coming to the PTG. Kendall Nelson and Mike
>> Perez will soon announce the details for this, including how projects
>> can sign up.
>> 
>> 3/ Free hacking/meetup space
>> 
>> We'll have four or five rooms populated with roundtables for ad-hoc
>> discussions and hacking. We don't have specific plans for these -- we
>> could set up something like the PTG ethercalc for teams to book the
>> space, or keep it open. Maybe half/half.
>> 
>> More details on all this as they come up.
>> Hoping to see you there !
>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ian Y. Choi]

Doug Hellmann wrote on 3/9/2017 9:24 PM:

Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:

On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

On 2017-03-06 14:03, Sean Dague  wrote:

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and

thus our tools do not handle them anymore - and in general, we remove
these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

So... just looking for a definitive statement on this since there has
been some back and forth discussion.

Is it correct to say - all projects may (should?) now remove all bits in
place for using and enforcing the _Lx() translation markers. Only _()
should be used for user visible error messages.

Sean (smcginnis)


The situation is still not quite clear to me, and it would be
unfortunate to undo too much of the translation support work because
it will be hard to redo it.

Is there documentation somewhere describing what the i18n team has
committed to trying to translate?


I18n team describes translation plan and priority in Zanata - 
translation platform

 : https://translate.openstack.org/ .


  I think I heard that there was a
shift in emphasis to "user interfaces", but I'm not sure if that
includes error messages in services. Should we remove all use of
oslo.i18n from services? Or only when dealing with logs?


When I18n team decided to removal of log translations in Barcelona last 
October, there had been no

discussion on the removal of oslo.i18n translation support for log messages.
(I have kept track of what I18n team discussed during Barcelona I18n 
meetup on Etherpad - [1])


Now I think that the final decision of oslo.i18n log translation support 
needs more involvement
with translators considering oslo.i18n translation support, and also 
more people on community wide including

project working groups, user committee, and operators as Matt suggested.

If translating log messages is meaningful to some community members and 
some translators show interests
on translating log messages, then I18n team can revert the policy with 
rolling back of translations.
Translated strings are still alive in not only previous stable branches, 
but also in translation memory in Zanata - translation platform.


I would like to find some ways to discuss this topic with more community 
wide.



With many thanks,

/Ian

[1] https://etherpad.openstack.org/p/barcelona-i18n-meetup



Doug

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




__
OpenStack Development Mailing 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] Some information about the Forum at the Summit in Boston

[Ben Swartzlander]

I might be the only one who has negative feelings about the PTG/Forum 
split, but I suspect the foundation is suppressing negative feedback 
from myself and other developers so I'll express my feelings here. If 
there's anyone else who feels like me please reply, otherwise I'll 
assume I'm just an outlier.


The new structure is asking developers to travel 4 times a year 
(minimum) and makes it impossible to participate in 2 or more vertical 
projects.


I know that most of the people working on Manila have pretty limited 
travel budgets, and meeting 4 times a year basically guarantees that a 
good number of people will be remote at any given meeting. From my 
perspective if I'm going to be meeting with people on the phone I'd 
rather be on the phone myself and have everyone on equal footing.


I also normally try to participate in Cinder as well as Manila and the 
new PTG structures makes that impossible. I decided to try to be 
positive and to wait until after the PTG to make up my mind but having 
attended in Atlanta it was exactly as bad as I expected in terms of my 
ability to participate in Cinder.


I will be in Boston to try to develop a firsthand opinion of the new 
Forum format but as of now I'm pretty unhappy with the proposal. For 
Manila I'm proposing that the community either meets at PTG and skips 
conferences or meetings at conferences and skips PTGs going forward. I'm 
not going to ask everyone to travel 4 times a year.


-Ben Swartzlander
Manila PTL


On 03/07/2017 07:35 AM, Thierry Carrez wrote:

Hi everyone,

I recently got more information about the space dedicated to the "Forum"
at the OpenStack Summit in Boston. We'll have three different types of
spaces available.

1/ "Forum" proper

There will be 3 medium-sized fishbowl rooms for cross-community
discussions. Topics for the discussions in that space will be selected
and scheduled by a committee formed of TC and UC members, facilitated by
Foundation staff members. In case you missed it, the brainstorming for
topics started last week, announced by Emilien in that email:

http://lists.openstack.org/pipermail/openstack-dev/2017-March/113115.html

2/ "On-boarding" rooms

We'll have two rooms set up in classroom style, dedicated to project
teams and workgroups who want to on-board new team members. Those can
for example be booked by project teams to run an introduction to their
codebase to prospective new contributors, in the hope that they will
join their team in the future. Those are not meant to do traditional
user-facing "project intro" talks -- there is space in the conference
for that. They are meant to provide the next logical step in
contributing after Upstream University and being involved on the
sidelines. It covers the missing link for prospective contributors
between attending Summit and coming to the PTG. Kendall Nelson and Mike
Perez will soon announce the details for this, including how projects
can sign up.

3/ Free hacking/meetup space

We'll have four or five rooms populated with roundtables for ad-hoc
discussions and hacking. We don't have specific plans for these -- we
could set up something like the PTG ethercalc for teams to book the
space, or keep it open. Maybe half/half.

More details on all this as they come up.
Hoping to see you there !



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

Re: [OpenStack-Infra] [zuul] Feedback requested for tox job definition

[Clark Boylan]

On Wed, Mar 8, 2017, at 07:20 AM, Paul Belanger wrote:
> 
> Greetings,
> 
> Allow me to bring to your attention a series of patches which create our
> first
> zuulv3 jobs. Specifically, we are looking to discuss what a generic tox
> job in
> ansible will look like.
> 
> Currently, we have 2 proposed patches for zuul (feature/zuulv3) branch
> available:
> 
> Generic tox (single playbook)
> - https://review.openstack.org/438281
> 
> Generic tox (multi playbook)
> - https://review.openstack.org/442180
> 
> Starting with 438281, the main differences lay within the .zuul.yaml
> file. As
> you can see by looking at the code, we are not defining any variables
> (vars) in
> .zuul.yaml. This means, we create 3 separate playbooks (tox-cover.yaml, 
> tox-py27, tox-linters.yaml) which then contain the variables we need for
> our tox
> role.
> 
> With 442180, we move our tox role variables into .zuul.yaml (vars
> section) and
> use a single playbook (tox.yaml) as our entry point for each job.
> 
> Everything else between the 2 patches is the same. So, with that in mind,
> which
> patch do people prefer?

I agree with others that have said both setups are readable and
understandable. I do have a slight preference for the multi playbook
approach as that treats the .zuul.yaml as a very high level overview of
what jobs should be run so you can get a sense for things easily without
worrying about implementation details.

Judging on how our JJB configs have evolved over time I am sure these
will evolve and change as well. So probably best to just pick one and
use it for a bit and go from there (with my slight preference being
multi playbook to start).

Also reading these job defs and comparing against the zuulv3 spec it
isn't clear to me what the expected behavior for inheriting pre and post
playbooks is. Seems like maybe pre is a queue so parent pre roles run
first and post is a stack so parent post roles run last? If that is
already written down and I am just missing it sorry for the noise, if it
isn't written down maybe we can do that?

Thanks,
Clark

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

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Hi Igor,

I was trying on Ubuntu 14.04 (trusty). This was weird though.

On Thu, Mar 9, 2017 at 4:54 PM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi Vikash,
>
>
>
> What OS were you trying on before?
>
>
>
> Best regards,
>
> Igor.
>
>
>
> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
> *Sent:* Thursday, March 9, 2017 10:08 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; ke...@benton.pub
>
> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
> "import error: vlanmanager"
>
>
>
> Tried on Ubuntu 16.04, its fine.
>
>
>
> On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar <
> vikash.ku...@oneconvergence.com> wrote:
>
> Import path looks OK
> https://github.com/openstack/networking-sfc/blob/master/
> networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23
>
>
>
> Are u suggesting something else?
>
>
>
> On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton  wrote:
>
> That location was recently changed in the Neutron side.[1] It sounds like
> sfc has to be updated.
>
>
>
> 1. https://github.com/openstack/neutron/commit/
> 4ec456d31501f09c68b5c23c488878da32dce75e
>
>
>
> On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar  com> wrote:
>
> Hi Igor,
>
>This is weird. I just did a fresh clone and executed *"tox" *command.
> I am getting same error. Am I missing anything here ? There is no private
> change here.  Below is the link for entire log.
>
>  http://paste.openstack.org/show/601870/
>
>
>
> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
> igor.duarte.card...@intel.com> wrote:
>
> Hi Vikash,
>
> Please stick to pastebin for complete logs.
>
>
>
> Check your migration files:
>
>
>
> FAILED: Contract HEAD file does not match migration timeline head,
> expected: 48072cb59133
>
>
>
> Best regards,
>
> Igor.
>
>
>
> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
> *Sent:* Tuesday, March 7, 2017 5:03 PM
> *To:* openstack-dev 
> *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due to
> "import error: vlanmanager"
>
>
>
> Complete log:
>
>  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
> py35 installdeps: 
> -r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt,
> -r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
> py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
> py35 installed: 
> /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
> DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
> "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,
> anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,
> beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,
> cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==
> 4.3.4,cryptography==1.7.2,debtcollector==1.12.0,
> decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet=
> =0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.
> 0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking=
> =0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601=
> =0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,
> keystoneauth1==2.18.0,keystonemiddleware==4.14.0,
> kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,
> logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.
> 1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==
> 0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e git+https://github.com/
> openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc2
> 0d2e484490#egg=networking_sfc,-e git+https://github.com/
> openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a
> 72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,
> openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==
> 1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==
> 3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==
> 4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.
> 18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.
> reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.
> 17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.
> versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==
> 2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.
> 0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,
> pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable=
> =0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.
> 5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,
> pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==
> 2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,
> python-designateclient==2.6.0,python-editor==1.0.3,python-
> glanceclient==2.6.0,python-keystoneclient==3.10.0,python-
> mimeparse==1.6.0,python-neutronclient==6.1.0,python-
> novaclient==7.1.0,python-openstackclient==3.8.1,python-
> 

Re: [OpenStack-Infra] [zuul] Feedback requested for tox job definition

[Andreas Jaeger]

Thanks, Paul.

For me both have their strength and weaknesses:

* If you want to add a new tox job for an existing target like pep8, I
like how simple that is with
https://review.openstack.org/#/c/438281/25/.zuul.yaml

* On the other hand, if you add a new tox job - for a completely new
target, then https://review.openstack.org/#/c/442180/3/.zuul.yaml allows
me to add the job in a single place instead of adding another file like
https://review.openstack.org/#/c/438281/25/playbooks/tox-cover.yaml.

Knowing that most projects do not add their own non-standard jobs, the
more compact setting like 438281 wins for me - and the other way is not
too difficult either.

So, I'm fine with either solution and have a slight preference to 438281.

I fear only time will tell, whether there's really a significant
difference ;)

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

[openstack-dev] Hitachi Data Systems drivers

[José Eduardo de Carvalho Mello Junior]

Dear community members,



Effective, Mar 9, 2017, Hitachi Data Systems will offer its drivers for
download exclusively via https://support.hds.com. Should you need
assistance with drivers, please contact
https://community.hds.com/community/developer-network/open-source/openstack.



Regards,

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

Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from LBaaS v1 to v2

[Saverio Proto]

Hello,

I managed to do the database migration.

I had to skip this logic:
https://github.com/openstack/neutron-lbaas/blob/master/tools/database-migration-from-v1-to-v2.py#L342-L353

I had to force flag=True

That code obviously breaks if you have LBaaS used by more than 1 tenant.

What was the goal ? to make sure that a given healthmonitor is not
reused in multiple pools ?

Should the right approach be to check if these two values are the same ?:

select count(DISTINCT monitor_id) from poolmonitorassociations;
select count(monitor_id) from poolmonitorassociations;

Second question: should the old tables from LBaaSV1 be dropped ?

Please give me feedback so I can fix the code and submit a review.

thank you

Saverio


On 09/03/17 13:38, Saverio Proto wrote:
>> I would recommend experimenting with the database-migration-from-v1-to-v2.py
>> script and working with your vendor (if you are using a vendor load
>> balancing engine) on a migration path.
> 
> 
> Hello,
> there is no vendor here to help us :)
> 
> I made a backup of the current DB.
> 
> I identified this folder on our Neutron server:
> 
> /usr/lib/python2.7/dist-packages/neutron_lbaas/db/migration ; tree
> .
> |-- alembic_migrations
> |   |-- env.py
> |   |-- env.pyc
> |   |-- __init__.py
> |   |-- __init__.pyc
> |   |-- README
> |   |-- script.py.mako
> |   `-- versions
> |   |-- 364f9b6064f0_agentv2.py
> |   |-- 364f9b6064f0_agentv2.pyc
> |   |-- 4b6d8d5310b8_add_index_tenant_id.py
> |   |-- 4b6d8d5310b8_add_index_tenant_id.pyc
> |   |-- 4ba00375f715_edge_driver.py
> |   |-- 4ba00375f715_edge_driver.pyc
> |   |-- 4deef6d81931_add_provisioning_and_operating_statuses.py
> |   |-- 4deef6d81931_add_provisioning_and_operating_statuses.pyc
> |   |-- CONTRACT_HEAD
> |   |-- EXPAND_HEAD
> |   |-- kilo_release.py
> |   |-- kilo_release.pyc
> |   |-- lbaasv2.py
> |   |-- lbaasv2.pyc
> |   |-- lbaasv2_tls.py
> |   |-- lbaasv2_tls.pyc
> |   |-- liberty
> |   |   |-- contract
> |   |   |   |-- 130ebfdef43_initial.py
> |   |   |   `-- 130ebfdef43_initial.pyc
> |   |   `-- expand
> |   |   |-- 3345facd0452_initial.py
> |   |   `-- 3345facd0452_initial.pyc
> |   |-- mitaka
> |   |   `-- expand
> |   |   |-- 3426acbc12de_add_flavor_id.py
> |   |   |-- 3426acbc12de_add_flavor_id.pyc
> |   |   |-- 3543deab1547_add_l7_tables.py
> |   |   |-- 3543deab1547_add_l7_tables.pyc
> |   |   |-- 4a408dd491c2_UpdateName.py
> |   |   |-- 4a408dd491c2_UpdateName.pyc
> |   |   |-- 62deca5010cd_add_tenant_id_index_for_l7_tables.py
> |   |   |-- 62deca5010cd_add_tenant_id_index_for_l7_tables.pyc
> |   |   |-- 6aee0434f911_independent_pools.py
> |   |   `-- 6aee0434f911_independent_pools.pyc
> |   |-- start_neutron_lbaas.py
> |   `-- start_neutron_lbaas.pyc
> |-- __init__.py
> `-- __init__.pyc
> 
> 7 directories, 40 files
> 
> Now here it says: "Create a revision file"
> 
> https://github.com/openstack/neutron-lbaas/blob/master/tools/database-migration-from-v1-to-v2.py#L30
> 
> There is some specific openstack-dev documentation to "Create a revision
> file" or I should just learn the Alembic tool ? I never used it before.
> 
> So far I did copy the alembic.ini from here:
> https://github.com/openstack/neutron/blob/master/neutron/db/migration/alembic.ini
> 
> into /usr/lib/python2.7/dist-packages/neutron_lbaas/db/migration
> 
> then I did run the command:
> 
> alembic revision -m "migrate to LBaaSv2"
> 
> as a result it created the file:
> /usr/lib/python2.7/dist-packages/neutron_lbaas/db/migration/alembic_migrations/versions/24274573545b_migrate_to_lbaasv2.py
> 
> Then I added the script to that file:
> wget -O -
> https://raw.githubusercontent.com/openstack/neutron-lbaas/master/tools/database-migration-from-v1-to-v2.py
>>> alembic_migrations/versions/24274573545b_migrate_to_lbaasv2.py
> 
> I tried now:
> neutron-db-manage upgrade heads
> 
> but it fails with a easy stacktrace. I get stuck here:
> https://github.com/openstack/neutron-lbaas/blob/master/tools/database-migration-from-v1-to-v2.py#L346
> 
> of course the query:
> select tenant_id from pools;
> 
> returns more than 1 tenant_id
> 
> it means I cannot migrate if I have more than 1 tenant using LBaaS v1 ?
> 
> am I doing something completely wrong here ? am I on the right direction ?
> 
> thank you
> 
> Saverio
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[McLellan, Steven]

I concur; option 4 is the only one makes sense to me and was what was intended 
originally. As long as we can do it in one fell swoop in one cyclle (preferably 
sooner than later) there should be no issues.




On 3/9/17, 8:35 AM, "Tripp, Travis S"  wrote:

>Let me get Matt B in on this discussion, but basically, option 4 is my initial 
>feeling as Rob stated.
>
>One downside we saw with this approach is that we weren’t going to be able to 
>take advantage of searchlight capabilities in details pages if everything was 
>in native horizon.  Although, I suppose that could be done by using the 
>hz-if-services directive [0] if horizon will allow searchlight optimized code 
>to be in the horizon repo.
>
>[0] 
>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>
>-Travis
>
>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:
>
>I tried searching the meeting logs but couldn’t find where we discussed 
> this in the Searchlight meeting. The conclusion at the time was option 4 
> IIRC. The main thing is to make sure we get it done within one cycle, even if 
> it isn’t default. this means searchlight-ui doesn’t have to carry some 
> horrible workarounds and can just remove the code from their repo.
>
>Basically; start putting the code in the Horizon repo, and when its done, 
> Searchlight-UI can remove it from their repo.
>
>Rob
>
>
>> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
>> 
>> Hi Searchlight and Horizon folks,
>> 
>> I'd like to re-use the wonderful resource type code from
>> searchlight-ui (in particular os-nova-servers right now but
>> potentially others down the track) and was wondering whether you'd had
>> any thoughts about how we might share that code? Off the top of my
>> head I see a few options:
>> 
>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>> pretty unlikely to happen (depending on any optional panel means it's
>> not really optional any longer ;-)
>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
> terrible.
>> 3. We move the code from searchlight-ui into a separate project that
>> both Horizon and searchlight-ui depend upon; this could be made to
>> work, though it's Yet Another Project.
>> 4. We move the code from searchlight-ui into Horizon. I think this is
>> most likely to work.
>> 
>> What are your thoughts? Have I missed an option in this list that you
>> think is a better one? Have I missed the mark in my analysis of the
>> options I've presented?
>> 
>> 
>>  Richard
>> 
>> 
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] ironickers and mascot at Pike PTG (or "where's Waldo?")

[Loo, Ruby]

Dmitry, our fearless PTL, looks like the tallest person in the group. Is that 
what happens when you become PTL, or is it a requirement to be PTL? :)

Many thanks to  that organized and took this picture at the 
Pike PTG:

https://www.flickr.com/photos/152419717@N06/32926952872/in/album-72157680602754246/

--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] Pike PTG report

[Loo, Ruby]

Thanks Dmitry for the great report! If you want your comment(s) to be available 
to the ironic community, please respond here, not in Dmitry's blog. (Or, to 
rephrase it a different way, if you have comments that you don't want me to 
know about, please respond in Dmitry's blog :))

Many thanks to Michael Turek for taking great notes during the PTG. Speaking of 
which, we did have some informal discussions Friday morning, but Michael wasn't 
there :)

--ruby

On 2017-03-08, 10:06 AM, "Dmitry Tantsur"  wrote:

Hi all!

I've finished my Pike PTG report. It is spread over four blog posts:

http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-1.html
http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-2.html
http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-3.html
http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-4.html

It was a lot of typing, please pardon mistakes. The whole text (in RST 
format) 
for archiving purposes is copy-pasted in the end of this message.

Please feel free to respond here or in the blog comments.

Cheers,
Dmitry


Ongoing work and status updates
---

Etherpad: https://etherpad.openstack.org/p/ironic-pike-ptg-ongoing-work.

We spent the first half of Wednesday discussing this. There was a lot of
incomplete work left from Ocata, and some major ongoing work that we did not
even plan to finish in Ocata.

Boot-from-volume


Got some progress, most of the Ironic patches are up. Desperately needs 
review
and testing, though. The Nova part is also lagging behind, and should be
brought to the Nova team attention.

**Actions**
 **mgoddard** and **dtantsur** volunteered to help with testing, while
 **mjturek**, **hsiina** and **crushil** volunteered to do some coding.
**Goals for Pike**
 finish the first (iSCSI using iPXE) case and the Nova part.

Networking
~~

A lot of progress here during Ocata, completed bonding and attach/detach 
API.

VLAN-aware instances should work. However, it requires an expensive ToR 
switch,
supporting VLAN/VLAN and VLAN/VXLAN rewriting, and, of course ML2 plugin
support. Also, reusing an existing segmentation ID requires more work: we 
have
no current way to put the right ID in the configdrive.

**Actions**
 **vsaienko**, **armando** and **kevinbenton** are looking into the 
Neutron
 part of the configdrive problem.

Routed networks support require Ironic to be aware of which physical 
network(s)
each node is connected to.

**Goals for Pike**
 * model physical networks on Ironic ports,
 * update VIF attach logic to no longer attach things to wrong physnets.

We discussed introducing notifications from Neutron to Ironic about events
of interest for us. We are going to use the same model as between Neutron 
and
Nova: create a Neutron plugin that filters out interesting events and posts
to a new Ironic API endpoint.

**Goals for Pike**
 have this notification system in place.

Finally, we agreed that we need to work on a reference architecture 
document,
describing the best practices of deploying Ironic, especially around
multi-tenant networking setup.

**Actions**
 **jroll** to kickstart this document, **JayF** and **mariojv** to help.

Rolling upgrades


Missed Ocata by a small margin. The code is up and needs reviewing. The CI
is waiting for the multinode job to start working (should be close as well).

**Goals for Pike**
 rolling upgrade Ocata -> Pike.

Driver composition reform
~

Most of the code landed in Ocata already. Some client changes landed in 
Pike,
some are still on review. As we released Ocata with the driver composition
changes being experimental, we are not ready to deprecate old-style drivers 
in
Pike. Documentation is also still lacking.

**Goals for Pike**
 * make new-style dynamic drivers the recommend way of writing and using
   drivers,
 * fill in missing documentation,
 * *recommend* vendors to have hardware types for their hardware, as 
well
   as 3rdparty CI support for it.
**Important decisions**
 * no new classic drivers are accepted in-tree (please check when 
accepting
   specifications),
 * no new interfaces additions for classic drivers(``volume_interface`` 
is
   the last accepted from them),
 * remove the SSH drivers by Pike final (probably around M3).

Ironic Inspector HA
~~~

Preliminary work (switch to a real state machine) done in Ocata. Splitting 
the
service into API 

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Tripp, Travis S]

Let me get Matt B in on this discussion, but basically, option 4 is my initial 
feeling as Rob stated.

One downside we saw with this approach is that we weren’t going to be able to 
take advantage of searchlight capabilities in details pages if everything was 
in native horizon.  Although, I suppose that could be done by using the 
hz-if-services directive [0] if horizon will allow searchlight optimized code 
to be in the horizon repo.

[0] 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js

-Travis

On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)"  wrote:

I tried searching the meeting logs but couldn’t find where we discussed 
this in the Searchlight meeting. The conclusion at the time was option 4 IIRC. 
The main thing is to make sure we get it done within one cycle, even if it 
isn’t default. this means searchlight-ui doesn’t have to carry some horrible 
workarounds and can just remove the code from their repo.

Basically; start putting the code in the Horizon repo, and when its done, 
Searchlight-UI can remove it from their repo.

Rob


> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
> 
> Hi Searchlight and Horizon folks,
> 
> I'd like to re-use the wonderful resource type code from
> searchlight-ui (in particular os-nova-servers right now but
> potentially others down the track) and was wondering whether you'd had
> any thoughts about how we might share that code? Off the top of my
> head I see a few options:
> 
> 1. We depend on the searchlight-ui as a Horizon requirement; this is
> pretty unlikely to happen (depending on any optional panel means it's
> not really optional any longer ;-)
> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
terrible.
> 3. We move the code from searchlight-ui into a separate project that
> both Horizon and searchlight-ui depend upon; this could be made to
> work, though it's Yet Another Project.
> 4. We move the code from searchlight-ui into Horizon. I think this is
> most likely to work.
> 
> What are your thoughts? Have I missed an option in this list that you
> think is a better one? Have I missed the mark in my analysis of the
> options I've presented?
> 
> 
>  Richard
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


__
OpenStack Development Mailing List (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] Ironic UI. Looking for feedback.

[Peter Piela]

The Ironic-UI development team is looking for feedback from operators to guide 
the development of new features and improve existing functionality. We would 
like to build a community of users that can help in defining the key use 
cases/stories that the Ironic-UI will deliver, and planning future development 
cycles. Please contact me directly if you are interested, or have questions.

Thank you for your attention.

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

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

[Jeremy Stanley]

On 2017-03-09 12:12:01 +0100 (+0100), Alan Pevec wrote:
> 2017-03-09 10:41 GMT+01:00 Alfredo Moralejo Alonso :
> > On Wed, Mar 8, 2017 at 12:44 PM, Steven Hardy  wrote:
> >> https://bugs.launchpad.net/tripleo/+bug/1669462
> >>
> >> I'm not clear on the best path forward at this point, but the simplest one
> >> suggested so far is to simply tag a new pre-milestone/alpha release for all
> >> master branches, which will enable testing upgrades to master.
> 
> That would be indeed simplest and cleanest solution but it has been
> rejected in the past, IIUC with reasoning that projects are not sure
> what will be their next version. IMHO that should not be the case if
> the project has decided to have a stable branch and follows semver and
> stable branch policy: in that case project will keep X.Y frozen on
> stable so master should be bumped to at least X.Y+1 immediately after
> branching stable.
[...]

In the past we addressed this by automatically merging the release
tag back into master, but we stopped doing that a cycle ago because
it complicated release note generation.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [neutron] [infra] Depends-on tag effect

[Hirofumi Ichihara]

On 2017/03/09 2:33, Armando M. wrote:



On 8 March 2017 at 07:39, Hirofumi Ichihara 
> wrote:




On 2017/03/08 23:59, Andreas Jaeger wrote:

On 2017-03-08 15:40, ZZelle wrote:

Hi,

iiuc, neutron uses a released version of neutron-lib not
neutron-lib
master ... So the change should depends on a change in
requirements repo
incrementing neutron-lib version

This is documented also at - together with some other caveats:


https://docs.openstack.org/infra/manual/developers.html#limitations-and-caveats



Thank you for the pointer. I understand.


You can do the reverse as documented in [1]: i.e. file a dummy patch 
against neutron-lib that pulls in both neutron's and neutron-lib 
changes. One example is [2]


[1] 
https://docs.openstack.org/developer/neutron-lib/review-guidelines.html

[2] https://review.openstack.org/#/c/386846/

That makes sense. I missed the documentation. Thank you for your help.




Hirofumi




Note a depends-on requirements won't work either - you really
need to
release it. Or you need to change the test to pull neutron-lib
from source,

Andreas

On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara

>> wrote:

 Hi,

 I thought that we can post neutron patch depending on
neutron-lib
 patch under review.
 However, I saw it doesn't work[1, 2]. In the patches,
neutron
 patch[1] has Depends-on tag with neutron-lib patch[2]
but the pep8
 and unit test fails because the test doesn't use the
neutron-lib patch.

 Please correct me if it's my misunderstanding.

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

 >
 [2]: https://review.openstack.org/#/c/424868/

 >

 Thanks,
 Hirofumi



   
 __

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

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

[Boris Bobrov]

Hi,

Please paste your mapping to paste.openstack.org

On 03/09/2017 02:07 AM, Evan Bollig PhD wrote:
> I am on Ocata with Shibboleth auth enabled. I noticed that Federated
> users with the admin role no longer have authorization to use the
> Admin** panels in Horizon related to Nova, Cinder and Neutron. All
> regular Identity and Project tabs function, and there are no problems
> with authorization for local admin users.
> 
> -
> These Admin tabs work: Hypervisors, Host Aggregates, Flavors, Images,
> Defaults, Metadata, System Information
> 
> These result in logout: Instances, Volumes, Networks, Routers, Floating IPs
> 
> This is not present: Overview
> -
> 
> The policies are vanilla from the CentOS/RDO openstack-dashboard RPMs:
> openstack-dashboard-11.0.0-1.el7.noarch
> python-django-horizon-11.0.0-1.el7.noarch
> python2-keystonemiddleware-4.14.0-1.el7.noarch
> python2-keystoneclient-3.10.0-1.el7.noarch
> openstack-keystone-11.0.0-1.el7.noarch
> python2-keystoneauth1-2.18.0-1.el7.noarch
> python-keystone-11.0.0-1.el7.noarch
> 
> The errors I see in logs are similar to:
> 
> ==> /var/log/horizon/horizon.log <==
> 2017-03-07 18:24:54,961 13745 ERROR horizon.exceptions Unauthorized:
> Traceback (most recent call last):
>   File 
> "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/floating_ips/views.py",
> line 53, in get_tenant_list
> tenants, has_more = api.keystone.tenant_list(request)
>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
> line 351, in tenant_list
> manager = VERSIONS.get_project_manager(request, admin=admin)
>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
> line 61, in get_project_manager
> manager = keystoneclient(*args, **kwargs).projects
>   File "/usr/share/openstack-dashboard/openstack_dashboard/api/keystone.py",
> line 170, in keystoneclient
> raise exceptions.NotAuthorized
> NotAuthorized
> 
> Cheers,
> -E
> --
> Evan F. Bollig, PhD
> Scientific Computing Consultant, Application Developer | Scientific
> Computing Solutions (SCS)
> Minnesota Supercomputing Institute | msi.umn.edu
> University of Minnesota | umn.edu
> boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556
> 
> __
> OpenStack Development Mailing List (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] [tc][appcat] The future of the App Catalog

[Jeremy Stanley]

On 2017-03-09 10:04:43 +0100 (+0100), Adam Heczko wrote:
[...]
> In regards to Application Catalog if OpenStack infra is not appropriate
> place for its hosting purposes maybe moving it to Github or similar hosting
> service should be considered.

I don't think there's anything wrong with the infra team continuing
to host the site/service if the community continues to consider it a
good idea. The concerns raised are mostly that it can look like an
NIH competition against much more successful cloud application
indexing services, causing those broader communities to continue to
regard us as adversarial reinventors of their particular wheels and
so hampering inter-community relationship building.
-- 
Jeremy Stanley

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

[Openstack-operators] OpenStack Operators Milan - Neutron Session

[Randy.Perryman]

Here is the etherpad for the Neutron Session in Milan
https://etherpad.openstack.org/p/MIL-ops-neutron

Please add to it anything you would like to cover.

Also will anyone from SDN Vendors be there?  Please come and provide a 5 minute 
update to your offering.

Thank You

Randy Perryman
Technical Staff, Cloud Architect
Certified OpenStack Administrator

Dell EMC | OpenSource Solutions Group
office + 01 603 249 7710
mobile +01 603 321 5611
email randy.perry...@dell.com
http://www.dell.com/cloud

Please consider the environment before printing this email.

Confidentiality Notice | This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential or 
proprietary information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, immediately 
contact the sender by reply e-mail and destroy all copies of the original 
message.


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

Re: [Openstack] Integrating Ceph Jewel as Storage Backend for OpenStack Newton

[Esteban Freire]

Hi Evan, all

I can confirm that integrating Ceph (Jewel) as Storage Backend for Glance, 
Cinder and Nova OpenStack (Newton) services can be done by following the steps 
described on, http://docs.ceph.com/docs/jewel/rbd/rbd-openstack/ 

Just a warning about it, the right Ceph configuration to apply on Glance, 
Cinder and Nova services is the one referring to Juno OpenStack release. I 
guess this should be updated and refer to Newton release or otherwise, it can 
be a bit confusing or at least, it was for me.

Also, in the example for the section about create a secret in virsh so KVM can 
access to Ceph pools, it is mentioned:

    client.cinder secret

I think "name" should be a single name according to 
https://libvirt.org/formatsecret.html. I think it works on both ways but in my 
opinion the best practice is to put a single name in here.   

I think the above is the only relevant to comment :)

Best regards,
Esteban
  
|  
|   |  
libvirt: Secret XML format
 libvirt, virtualization, virtualization API  |  |

  |

 
 

El Martes 7 de marzo de 2017 8:57, Esteban Freire  
escribió:
 

 Hi Evan,

Thanks for your answer :) 

Yes, I have defined similar permissions and users. 

After performing some tests, I realized that Glance was not able to read 
ceph.conf file because I did not have the right variables defined.

Now, I can confirm that the Glance (Newton) integration with Ceph (Jewel) works 
following the steps defined on 
http://docs.ceph.com/docs/jewel/rbd/rbd-openstack/ and with the following 
configuration (at least for my use case and in a fresh installation on CentOS 
7):

    [glance_store]
    stores = file,http,rbd
    default_store = rbd
    rbd_store_pool = images
    rbd_store_user = glance
    rbd_store_ceph_conf = /etc/ceph/ceph.conf
    rbd_store_chunk_size = 8

Currently, I am working on Cinder and Nova integration with Ceph. I will let 
you know when I manage to get it working. 

Cheers,
Esteban 

El Lunes 6 de marzo de 2017 18:08, Evan Bollig PhD  
escribió:
 

 Hey Esteban,
I got that same error at one point. Check your file permissions on the
/etc/ceph directory and contents. In particular, make sure the glance
user can access its keyring and the ceph.conf is readable for the
group as well. Here's an example:

drwxr-xr-x.  2 root    root    4.0K Jan 17 12:25 .
drwxr-xr-x. 93 root    root    8.0K Mar  3 14:27 ..
-rw---.  1 root    root      63 Jan 11 14:00 ceph.client.admin.keyring
-rw---.  1 cinder  cinder    71 Jan 11 13:59
ceph.client.cinder-backup.keyring
-r+  1 cinder  cinder    64 Jan 11 13:59 ceph.client.cinder.keyring
-rw---.  1 glance  glance    64 Jan 11 13:59 ceph.client.glance.keyring
-r+  1 gnocchi gnocchi  65 Jan 17 12:25 ceph.client.gnocchi.keyring
-rw-r--r--.  1 root    root    220 Jan 11 13:59 ceph.conf

Let me know how things in Newton are working; we're only as far as
Mitaka at the moment.

Cheers,
-E


--
Evan F. Bollig, PhD
Scientific Computing Consultant, Application Developer | Scientific
Computing Solutions (SCS)
Minnesota Supercomputing Institute | msi.umn.edu
University of Minnesota | umn.edu
boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556


On Thu, Mar 2, 2017 at 3:13 AM, Esteban Freire  wrote:
> Hello all,
>
> I am testing OpenStack Newton on CentOS 7 and now I already have a OpenStack
> cloud infrastructure working, I would like to integrate Ceph with Cinder,
> Glance and Nova services.
>
> I have found some information about how to performance this on previous
> releases for Openstack and Ceph:
>
>    http://docs.ceph.com/docs/jewel/rbd/rbd-openstack/
>
> And I tried to update the variables according to
> https://docs.openstack.org/newton/config-reference/block-storage/drivers/ceph-rbd-volume-driver.html
>
> This is my current glance-api.conf and which is working:
>
>    [glance_store]
>    stores = file,http
>    default_store = file
>    filesystem_store_datadir = /var/lib/glance/images/
>
>
> At this is what I tried (at the moment, I have only tried it with the glance
> service but I did not get success):
>
>    * Install python-rbd and python-rados from centos-ceph-jewel repo on the
> controller node.
>    * Create a ceph user and add it to sudoers.
>    * On ceph admin node:
>
>        sudo ceph osd pool create images 150
>        sudo ceph auth get-or-create client.glance mon 'allow r' osd 'allow
> class-read object_prefix rbd_children, allow rwx pool=images'
>        sudo ceph auth get-or-create client.glance | ssh
> ceph@controller-node1 sudo tee /etc/ceph/ceph.client.glance.keyring
>        ssh ceph@controller-node1 sudo chown glance:glance
> /etc/ceph/ceph.client.glance.keyring
>
>    * On the controller node, I edited the glance-api.conf file with the
> following variables:
>
>        [glance_store]
>        stores = file,http,rbd
>        default_store = rbd
>        rbd_pool = images
>        rbd_user = glance
>        rbd_ceph_conf = 

[openstack-dev] [Watcher] onboarding room at the Forum

[Alexander Chadin]

Watcher folks,

I’ve got a proposal from Kendall Nelson, who wants to know whether we want to 
reserve a room for discussions and chat with people or not.

I suggest to choose a slot from 4 to 6 pm on 9 May, Tuesday.
It allows us to visit Marketplace and interesting presentations in the morning 
and afternoon.

Please, vote for the time. If you aren’t agree with current proposition, feel 
free to share yours.

Best Regards,
_
Alexander Chadin
OpenStack Developer
Servionica LTD
a.cha...@servionica.ru
+7 (916) 693-58-81

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

Re: [openstack-dev] [Neutron][LBaaS] - Best release to upgrade from LBaaS v1 to v2

[Saverio Proto]

> I would recommend experimenting with the database-migration-from-v1-to-v2.py
> script and working with your vendor (if you are using a vendor load
> balancing engine) on a migration path.


Hello,
there is no vendor here to help us :)

I made a backup of the current DB.

I identified this folder on our Neutron server:

/usr/lib/python2.7/dist-packages/neutron_lbaas/db/migration ; tree
.
|-- alembic_migrations
|   |-- env.py
|   |-- env.pyc
|   |-- __init__.py
|   |-- __init__.pyc
|   |-- README
|   |-- script.py.mako
|   `-- versions
|   |-- 364f9b6064f0_agentv2.py
|   |-- 364f9b6064f0_agentv2.pyc
|   |-- 4b6d8d5310b8_add_index_tenant_id.py
|   |-- 4b6d8d5310b8_add_index_tenant_id.pyc
|   |-- 4ba00375f715_edge_driver.py
|   |-- 4ba00375f715_edge_driver.pyc
|   |-- 4deef6d81931_add_provisioning_and_operating_statuses.py
|   |-- 4deef6d81931_add_provisioning_and_operating_statuses.pyc
|   |-- CONTRACT_HEAD
|   |-- EXPAND_HEAD
|   |-- kilo_release.py
|   |-- kilo_release.pyc
|   |-- lbaasv2.py
|   |-- lbaasv2.pyc
|   |-- lbaasv2_tls.py
|   |-- lbaasv2_tls.pyc
|   |-- liberty
|   |   |-- contract
|   |   |   |-- 130ebfdef43_initial.py
|   |   |   `-- 130ebfdef43_initial.pyc
|   |   `-- expand
|   |   |-- 3345facd0452_initial.py
|   |   `-- 3345facd0452_initial.pyc
|   |-- mitaka
|   |   `-- expand
|   |   |-- 3426acbc12de_add_flavor_id.py
|   |   |-- 3426acbc12de_add_flavor_id.pyc
|   |   |-- 3543deab1547_add_l7_tables.py
|   |   |-- 3543deab1547_add_l7_tables.pyc
|   |   |-- 4a408dd491c2_UpdateName.py
|   |   |-- 4a408dd491c2_UpdateName.pyc
|   |   |-- 62deca5010cd_add_tenant_id_index_for_l7_tables.py
|   |   |-- 62deca5010cd_add_tenant_id_index_for_l7_tables.pyc
|   |   |-- 6aee0434f911_independent_pools.py
|   |   `-- 6aee0434f911_independent_pools.pyc
|   |-- start_neutron_lbaas.py
|   `-- start_neutron_lbaas.pyc
|-- __init__.py
`-- __init__.pyc

7 directories, 40 files

Now here it says: "Create a revision file"

https://github.com/openstack/neutron-lbaas/blob/master/tools/database-migration-from-v1-to-v2.py#L30

There is some specific openstack-dev documentation to "Create a revision
file" or I should just learn the Alembic tool ? I never used it before.

So far I did copy the alembic.ini from here:
https://github.com/openstack/neutron/blob/master/neutron/db/migration/alembic.ini

into /usr/lib/python2.7/dist-packages/neutron_lbaas/db/migration

then I did run the command:

alembic revision -m "migrate to LBaaSv2"

as a result it created the file:
/usr/lib/python2.7/dist-packages/neutron_lbaas/db/migration/alembic_migrations/versions/24274573545b_migrate_to_lbaasv2.py

Then I added the script to that file:
wget -O -
https://raw.githubusercontent.com/openstack/neutron-lbaas/master/tools/database-migration-from-v1-to-v2.py
>> alembic_migrations/versions/24274573545b_migrate_to_lbaasv2.py

I tried now:
neutron-db-manage upgrade heads

but it fails with a easy stacktrace. I get stuck here:
https://github.com/openstack/neutron-lbaas/blob/master/tools/database-migration-from-v1-to-v2.py#L346

of course the query:
select tenant_id from pools;

returns more than 1 tenant_id

it means I cannot migrate if I have more than 1 tenant using LBaaS v1 ?

am I doing something completely wrong here ? am I on the right direction ?

thank you

Saverio














__
OpenStack Development Mailing List (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] [ptl][oslo] Oslo weekly meeting changed!

[ChangBo Guo]

Hello, fellow PTLs,

Oslo libraries are used among many OpenStack projects, in this thread I'm
trying to explain Oslo team daily work to
make us work together smoothly.

You can find most of information in https://wiki.openstack.org/wiki/Oslo, I
would like to highlight import things :-)

1. weekly meeting:
   We recently changed the Oslo weekly meeting at 1400 UTC on Monday at
#openstack-meeting-3
   All are welcome to participate, please update your Oslo liaison on
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo
   and add discussion item in
https://etherpad.openstack.org/p/oslo-pike-tracking before weekly meeting.
   To be pinged before a meeting starts please (add or remove) IRC names
from: https://github.com/openstack/oslo.tools/blob/master/ping_me.py

2. weekly release:
   We usually do weekly release like
https://review.openstack.org/#/c/442006/, please ping me if you want to
delay some libraries release to include
  specific fix.

3. Propose new ideas and  abstract common codes

  If you find some duplicated code among OpenStack Project or have common
requirement for different projects. Just post them to Oslo.
-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:
> On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
> > On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> > > On 2017-03-06 14:03, Sean Dague  wrote:
> > >> I'm trying to understand the implications of
> > >> https://review.openstack.org/#/c/439500. And the comment in the linked
> > >> email:
> > >>
> > >> ">> Yes, we decided some time ago to not translate the log files anymore 
> > >> and
> >  thus our tools do not handle them anymore - and in general, we remove
> >  these kind of files."
> > >>
> > >> Does that mean that all the _LE, _LI, _LW stuff in projects should be
> > >> fully removed? Nova currently enforces those things are there -
> > >> https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
> > >> and want to make sure our tools aren't making us do work that the i18n
> > >> team is ignoring and throwing away.
> > > 
> 
> So... just looking for a definitive statement on this since there has
> been some back and forth discussion.
> 
> Is it correct to say - all projects may (should?) now remove all bits in
> place for using and enforcing the _Lx() translation markers. Only _()
> should be used for user visible error messages.
> 
> Sean (smcginnis)
> 

The situation is still not quite clear to me, and it would be
unfortunate to undo too much of the translation support work because
it will be hard to redo it.

Is there documentation somewhere describing what the i18n team has
committed to trying to translate? I think I heard that there was a
shift in emphasis to "user interfaces", but I'm not sure if that
includes error messages in services. Should we remove all use of
oslo.i18n from services? Or only when dealing with logs?

Doug

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

Re: [openstack-dev] [Neutron] ImportError: No module named neutron_lib

[Doug Hellmann]

Excerpts from Sam's message of 2017-03-09 14:33:11 +0800:
> Sorry, it's oslo_db, I'm wrong

The "Drop our use of namespace packages" spec explains why.

http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html

Doug

> 
> 2017-03-09 14:22 GMT+08:00 Sam :
> 
> > I found this:
> >
> > from oslo_config import ...
> > from oslo_db import ...
> > from neutron_lib import ...
> >
> > actually these libraries is oslo.config, oslo.db, neutron.lib
> >
> > Why not write like this: from oslo.config import ... ?
> >
> > And for local package, its: from neutron.api import ...
> >
> > WHY ?
> >
> > 2017-03-08 5:28 GMT+08:00 Tony Breeds :
> >
> >> On Tue, Mar 07, 2017 at 04:04:55PM +0800, Sam wrote:
> >> > Is this?
> >> >
> >> > https://pypi.python.org/pypi/neutron-lib
> >>
> >> Make sure you're installing with upper-constratints otehrwise you'll get
> >> components that rely on features for newer releases
> >>
> >> Assuming you're installing with pip something like[1]
> >>
> >> wget 'http://tarballs.openstack.org/neutron/neutron-8.4.0-py2.py3
> >> -none-any.whl'
> >> wget 'http://git.openstack.org/cgit/openstack/requirements/plain/
> >> upper-constraints.txt?h=stable/mitaka'
> >>
> >> pip install -c upper-constratints.txt ./neutron-8.4.0-py2.py3-none-a
> >> ny.whl
> >>
> >> Should get you a stable/mitaka neutron with appropriate versions of all
> >> libraries in use.
> >>
> >> Yours Tony.
> >>
> >> [1] You may be able to pass the URLs directly to pip but I haven't tested
> >> that for wheels
> >>
> >> 
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
> >> e
> >> 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] [tc][appcat][murano][app-catalog] The future of the App Catalog

[Thierry Carrez]

Christopher Aedo wrote:
> On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez  wrote:
>> [...]
>> In parallel, Docker developed a pretty successful containerized
>> application marketplace (the Docker Hub), with hundreds of thousands of
>> regularly-updated apps. Keeping the App Catalog around (including its
>> thinly-wrapped Docker container Murano packages) make us look like we
>> are unsuccessfully trying to compete with that ecosystem, while
>> OpenStack is in fact completely complementary.
> 
> Without something like Murano "thinly wrapping" docker apps, how would
> you propose current users of OpenStack clouds deploy docker apps?  Or
> any other app for that matter?  It seems a little unfair to talk about
> murano apps this way when no reasonable alternative exists for easily
> deploying docker apps.  When I look back at the recent history of how
> we've handled containers (nova-docker, magnum, kubernetes, etc) it
> does not seem like we're making it easy for the folks who want to
> deploy a container on their cloud...

I'd say there are two approaches: you can use the container-native
approach ("docker run" after provisioning some container-enabled host
using Nova or K8s cluster using Magnum), or you can use the
OpenStack-native approach (zun create nginx) and have it
auto-provisioned for you. Those projects have a narrower scope, and
fully co-opt the container ecosystem without making us appear as trying
to build our own competitive application packaging/delivery/marketplace
mechanism.

I just think that adding the Murano abstraction in the middle of it and
using an AppCatalog-provided Murano-powered generic Docker container
wrapper is introducing unnecessary options and complexity -- options
that are strategically hurting us when we talk to those adjacent
communities...

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Rob Cresswell (rcresswe)]

I tried searching the meeting logs but couldn’t find where we discussed this in 
the Searchlight meeting. The conclusion at the time was option 4 IIRC. The main 
thing is to make sure we get it done within one cycle, even if it isn’t 
default. this means searchlight-ui doesn’t have to carry some horrible 
workarounds and can just remove the code from their repo.

Basically; start putting the code in the Horizon repo, and when its done, 
Searchlight-UI can remove it from their repo.

Rob


> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
> 
> Hi Searchlight and Horizon folks,
> 
> I'd like to re-use the wonderful resource type code from
> searchlight-ui (in particular os-nova-servers right now but
> potentially others down the track) and was wondering whether you'd had
> any thoughts about how we might share that code? Off the top of my
> head I see a few options:
> 
> 1. We depend on the searchlight-ui as a Horizon requirement; this is
> pretty unlikely to happen (depending on any optional panel means it's
> not really optional any longer ;-)
> 2. We copy the code from searchlight-ui into Horizon; this is pretty terrible.
> 3. We move the code from searchlight-ui into a separate project that
> both Horizon and searchlight-ui depend upon; this could be made to
> work, though it's Yet Another Project.
> 4. We move the code from searchlight-ui into Horizon. I think this is
> most likely to work.
> 
> What are your thoughts? Have I missed an option in this list that you
> think is a better one? Have I missed the mark in my analysis of the
> options I've presented?
> 
> 
>  Richard
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [Openstack] Trove is skipped in Newton

[Amrith Kumar]

Wang Sen, in what environment is this (x86 or non-x86)? I know of at least
three teams within IBM who have successfully deployed Trove on both x86 and
non-x86 systems and a number of different releases.

If you are interested, I'm happy to connect you with several of your fellow
IBM'ers who may be able to help you with this, or they may see this email
and reach out to you directly.

-amrith

-Original Message-
From: Wang Sen [mailto:wang...@linux.vnet.ibm.com] 
Sent: Thursday, March 9, 2017 2:32 AM
To: Mark Kirkwood 
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] Trove is skipped in Newton

I have been trying to deploy trove since last December, but my database
instances never escape from BUILD or Error state :(

On Tue, Mar 07, 2017 at 09:15:25PM +1300, Mark Kirkwood wrote:
> I haven't tried to get Trove working with latest versions - but 
> experience with previous (Kilo, Liberty, Mitaka) ones suggests that 
> the creation of guest images requires painstaking determination and 
> error checking - as the supplied docs are - somewhat - lacking...(read 
> between the lines here).
> 
> Best wishes
> 
> 
> Mark
> 
> On 07/03/17 20:13, Evgeniy Ivanov wrote:
> >Hello everybody,
> >
> >I found some interesting info about Trove in Newton. I'm able to 
> >deploy successfully some trove components (api, conductor and
> >taskmanager) on my test Newton environment. As for the Trove 
> >guestagent - I'm totally not able to run it neither on Ubuntu Trusty 
> >nor Ubuntu Xenial.
> >
> >I found there are no Newton packages for Trusty in The Ubuntu Cloud 
> >Archive. The last supported release is Mitaka (I checked the 
> >RELEASE_MAP). That looks there is no support for Newton in Trusty, 
> >therefore I can not use Trove in Newton.
> >
> >As for the Xenial release, here is a bug where Amrith Kumar (CTO
> >Tesora) says there is no support for Newton also -
> >https://bugs.launchpad.net/trove/+bug/1652312 (Should be in Ocata
> >only)
> >
> >For me, it looks like Tesora just skipped Newton, did they?
> >
> >I'm asking here because there is no way to get any answers from 
> >Tesora and Co.
> >
> >Thanks for any help!
> >
> 
> 
> ___
> 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] Trove is skipped in Newton

[Amrith Kumar]

Wang Sen, in what environment is this (x86 or non-x86)? I know of at least
three teams within IBM who have successfully deployed Trove on both x86 and
non-x86 systems and a number of different releases.

If you are interested, I'm happy to connect you with several of your fellow
IBM'ers who may be able to help you with this, or they may see this email
and reach out to you directly.

-amrith

-Original Message-
From: Wang Sen [mailto:wang...@linux.vnet.ibm.com] 
Sent: Thursday, March 9, 2017 2:32 AM
To: Mark Kirkwood 
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] Trove is skipped in Newton

I have been trying to deploy trove since last December, but my database
instances never escape from BUILD or Error state :(

On Tue, Mar 07, 2017 at 09:15:25PM +1300, Mark Kirkwood wrote:
> I haven't tried to get Trove working with latest versions - but 
> experience with previous (Kilo, Liberty, Mitaka) ones suggests that 
> the creation of guest images requires painstaking determination and 
> error checking - as the supplied docs are - somewhat - lacking...(read 
> between the lines here).
> 
> Best wishes
> 
> 
> Mark
> 
> On 07/03/17 20:13, Evgeniy Ivanov wrote:
> >Hello everybody,
> >
> >I found some interesting info about Trove in Newton. I'm able to 
> >deploy successfully some trove components (api, conductor and
> >taskmanager) on my test Newton environment. As for the Trove 
> >guestagent - I'm totally not able to run it neither on Ubuntu Trusty 
> >nor Ubuntu Xenial.
> >
> >I found there are no Newton packages for Trusty in The Ubuntu Cloud 
> >Archive. The last supported release is Mitaka (I checked the 
> >RELEASE_MAP). That looks there is no support for Newton in Trusty, 
> >therefore I can not use Trove in Newton.
> >
> >As for the Xenial release, here is a bug where Amrith Kumar (CTO
> >Tesora) says there is no support for Newton also -
> >https://bugs.launchpad.net/trove/+bug/1652312 (Should be in Ocata
> >only)
> >
> >For me, it looks like Tesora just skipped Newton, did they?
> >
> >I'm asking here because there is no way to get any answers from 
> >Tesora and Co.
> >
> >Thanks for any help!
> >
> 
> 
> ___
> 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-dev] [nova][docs] Broken nova instructions

[Alexandra Settle]

On 3/9/17, 11:18 AM, "John Garbutt"  wrote:

On 9 March 2017 at 11:05, Alexandra Settle  wrote:
> I have attached the error logs that our tester, Brian Moss, sent to me 
earlier this morning.
> He has noted that some people have been able to get the instructions to 
work, but many others haven't.
> Also, noted that some are failing on Ubuntu and RDO, so it isn't a distro 
specific problem either.

The current compute logs seem to point at this bug:
https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/issues/71

The bug says you restart libvirt and the problem goes away. Seems like
a package issue, maybe? I am not sure.

But then why would this issue present in RDO and Ubuntu? Seems random for those 
two to have a similar packaging problem, no?
Regardless, having to restart libvirt is hardly a great option.

I notice some 404s for flavors. You need to create your own flavors
before you can boot an instance. Not sure if thats covered in the
install docs.

For me I found the order unclear in the currently proposed docs, so I
revised them so the cells and placement logic is more integrated into
the existing steps in the guide.

Yep! Going to set up and test today. Will take a while as I’m going to go from 
the beginning.
Stay tuned.

Thanks :)

Thanks,
John

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


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

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Duarte Cardoso, Igor]

Hi Vikash,

What OS were you trying on before?

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Thursday, March 9, 2017 10:08 AM
To: OpenStack Development Mailing List (not for usage questions) 
; ke...@benton.pub
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Tried on Ubuntu 16.04, its fine.

On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar 
> wrote:
Import path looks OK
https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23



Are u suggesting something else?

On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton 
> wrote:
That location was recently changed in the Neutron side.[1] It sounds like sfc 
has to be updated.

1. 
https://github.com/openstack/neutron/commit/4ec456d31501f09c68b5c23c488878da32dce75e

On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar 
> wrote:
Hi Igor,
   This is weird. I just did a fresh clone and executed "tox" command. I am 
getting same error. Am I missing anything here ? There is no private change 
here.  Below is the link for entire log.

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

On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor 
> wrote:
Hi Vikash,
Please stick to pastebin for complete logs.

Check your migration files:

FAILED: Contract HEAD file does not match migration timeline head, expected: 
48072cb59133

Best regards,
Igor.

From: Vikash Kumar 
[mailto:vikash.ku...@oneconvergence.com]
Sent: Tuesday, March 7, 2017 5:03 PM
To: openstack-dev 
>
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Complete log:

 py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
py35 installdeps: 
-r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt, 
-r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
py35 installed: 
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated,  f = open(fullname, 
"rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
 
git+https://github.com/openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e
 

Re: [openstack-dev] [nova][docs] Broken nova instructions

[Andy McCrae]

On 9 March 2017 at 12:05, Alexandra Settle  wrote:

>
>
> On 3/9/17, 10:36 AM, "Sylvain Bauza"  wrote:
>
>
>
> Le 09/03/2017 11:25, Alexandra Settle a écrit :
> > Hi everyone,
> >
> >
> >
> > The installation guide for docs.o.o is currently broken and requires
> > immediate attention from the doc and nova teams.
> >
> >
> >
> > I have moved the relevant bug[0] to be CRITICAL at request. Brian
> Moss
> > (bmoss) and Amy Marrich (spotz) have been working on a subsequent
> patch
> > for the last 10 days without result; the current instruction set
> still
> > do not enable the user to start up an instance. There is another Red
> Hat
> > bug tracking the issue for RDO.[1]
> >
> >
>
> Just summarizing the thoughts on IRC, could we please have a clear
> understanding of the involved steps for installing greenfields, and
> what
> is the exception or problem subsequent ?
>
> The Installation Guide(s) at docs.o.o are the steps to installing
> Greenfields.
>
> I have attached the error logs that our tester, Brian Moss, sent to me
> earlier this morning.
> He has noted that some people have been able to get the instructions to
> work, but many others haven't.
> Also, noted that some are failing on Ubuntu and RDO, so it isn't a distro
> specific problem either.
>
> He has also tested the docs that are in-tree and were unable to get
> anything working from those either (I do not have Brian’s error logs from
> that incident). The instructions he has written for the patch[0] were based
> off these instructions.
>
> This obviously makes for a very ‘general’ problem, but one that is of
> major concern to us. At the moment, we have had plenty of reviews on the
> patch I originally referenced, and no one was able to agree on all the
> procedural steps.
>
> [0] https://review.openstack.org/#/c/438328/
>
> >
> > Any and all reviews on the patch[2] would be appreciated. We need to
> be
> > able to branch
> >
> >
>
> Sure, will do.
>
> Thank you :)
>
> We are concerned that this is something small we are potentially missing,
> something perhaps that devs aren't noticing it is missing because it’s
> ‘ingrained’.
> Essentially, we need the full procedure working for Greenfields. Any help
> is greatly appreciated!


Based on the log output I'd say that placement is setup properly (it's
responding to PUT/GET requests with 200/201 and seems fine).
I'd also say cells are setup fine - the instance was scheduled to the
compute host appropriately.

The errors look to be libvirt errors - is the libvirt service started
properly on the host? (as a start point).
Perhaps the libvirt setup bits in the install guide are incorrect or need
some additional steps there. I do know the group/service names and various
other things for libvirt changed with the newer libvirt version that is now
in UCA, but if this is a RDO install I'm not sure that is the same case.

Andy
__
OpenStack Development Mailing 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][docs] Broken nova instructions

[John Garbutt]

On 9 March 2017 at 11:05, Alexandra Settle  wrote:
> I have attached the error logs that our tester, Brian Moss, sent to me 
> earlier this morning.
> He has noted that some people have been able to get the instructions to work, 
> but many others haven't.
> Also, noted that some are failing on Ubuntu and RDO, so it isn't a distro 
> specific problem either.

The current compute logs seem to point at this bug:
https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/issues/71

The bug says you restart libvirt and the problem goes away. Seems like
a package issue, maybe? I am not sure.

I notice some 404s for flavors. You need to create your own flavors
before you can boot an instance. Not sure if thats covered in the
install docs.

For me I found the order unclear in the currently proposed docs, so I
revised them so the cells and placement logic is more integrated into
the existing steps in the guide.

Thanks,
John

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

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

[Alan Pevec]

2017-03-09 10:41 GMT+01:00 Alfredo Moralejo Alonso :
> On Wed, Mar 8, 2017 at 12:44 PM, Steven Hardy  wrote:
>> https://bugs.launchpad.net/tripleo/+bug/1669462
>>
>> I'm not clear on the best path forward at this point, but the simplest one
>> suggested so far is to simply tag a new pre-milestone/alpha release for all
>> master branches, which will enable testing upgrades to master.

That would be indeed simplest and cleanest solution but it has been
rejected in the past, IIUC with reasoning that projects are not sure
what will be their next version. IMHO that should not be the case if
the project has decided to have a stable branch and follows semver and
stable branch policy: in that case project will keep X.Y frozen on
stable so master should be bumped to at least X.Y+1 immediately after
branching stable.
For a project using PBR postversioning (almost all by now) this can be
achieved by either pushing the appropriate alpha git tag or by using
PBR Sem-Ver: feature https://docs.openstack.org/developer/pbr/#version
Now, purists would complain that artificial commit right after
branching is not really adding a feature but you could look at it as a
credit because you surely will implement new features in the new
version!
If project is without stable:follows-policy tag and it will keep
adding features on the stable branch, increasing Y part of semver or
if they already decided to bump X major version, Sem-Ver: api-break
can be used.
Example for TripleO projects for opening Ocata:
https://review.openstack.org/#/q/topic:open-ocata+Sem-Ver:

> As reference, puppet team proposed a solution for this issue in
> openstack puppet modules in
> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113494.html
>
> However, as mentioned before this is affecting all projects, not only
> puppet ones.

Solution for OpenStack Puppet modules is to explicitly set pre-version
in metadata.json.
We had used pre-versioning before in regular OpenStack projects by
setting version in setup.cfg but this has been abandoned and instead
we rely on PBR to compute the next version.

>> I know we don't expect to fully support upgrades to pre-milestone releases,
>> but the requirement here is to simply enable testing them.
>>
>> A side-benefit of this regular testing e.g via CI is we'll find upgrade 
>> issues
>> much faster than waiting for one or more milestone releases to happen then
>> doing an upgrade-debug firedrill later in the cycle (which has been bad for
>> project and deployment teams IMO, so it'd be good to figure out this first
>> step to enable earlier testing of upgrades to the development release).
>>
>> Any thoughts on how we can resolve this would be much appreciated, thanks!

I was suggested that upgrade jobs could force install i.e. basically
doing downgrades before milestone1 but that's not testing upgrades!
Versioning is very fundamental for packaging and reflects upstream
version, we cannot fake versions in packaging.
In the spirit of Continuous Everything, versioning should also be
continuous and ensured that master version is always > previous
releases.
Projects doing stable branches could take action individually using
Sem-Ver keyword but better would be to define this as a rule for
having stable branches and enforce it cross projects by the release
procedure.

Cheers,
Alan

__
OpenStack Development Mailing List (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] Milano session on Ops Telecom NFV

[Shintaro Mizuno]

Hi,

Here is a skeleton for Ops Telco-NFV session.
https://etherpad.openstack.org/p/MIL-ops-telco-nfv

Please feel free to add any items related to "OpenStack and Telecom/NFV" 
that you want to discuss.


Cheers,
Shintaro
--
Shintaro MIZUNO (水野伸太郎)
NTT Software Innovation Center
TEL: 0422-59-4977
E-mail: mizuno.shint...@lab.ntt.co.jp



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

Re: [openstack-dev] [nova][docs] Broken nova instructions

[Sylvain Bauza]

Le 09/03/2017 11:25, Alexandra Settle a écrit :
> Hi everyone,
> 
>  
> 
> The installation guide for docs.o.o is currently broken and requires
> immediate attention from the doc and nova teams.
> 
>  
> 
> I have moved the relevant bug[0] to be CRITICAL at request. Brian Moss
> (bmoss) and Amy Marrich (spotz) have been working on a subsequent patch
> for the last 10 days without result; the current instruction set still
> do not enable the user to start up an instance. There is another Red Hat
> bug tracking the issue for RDO.[1]
> 
>  

Just summarizing the thoughts on IRC, could we please have a clear
understanding of the involved steps for installing greenfields, and what
is the exception or problem subsequent ?

> 
> Any and all reviews on the patch[2] would be appreciated. We need to be
> able to branch
> 
>  

Sure, will do.

-Sylvain
> 
> Thank you,
> 
>  
> 
> Alex
> 
>  
> 
> [0] https://bugs.launchpad.net/openstack-manuals/+bug/1663485
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1405098
> 
> [2] https://review.openstack.org/#/c/438328/
> 
>  
> 
>  
> 
> 
> 
> __
> OpenStack Development Mailing List (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] Disable Mac and IP spoof protection

[Akihiro Motoki]

2017-03-09 16:59 GMT+09:00 Yura Poltoratskiy :
> Hi.
>
> We have OpenVZ as an instance, so there are many ip addresses on the
> instance. The only thing that I've done was disabling PortSecurity.
>
> If I'm correct, there is no way to update port for disabling PortSec, one
> have to delete port and to create a new with
> "--port-security-enabled=False".

You don't need to delete a port.
You can set port_security_enabled to False by:

neutron port-update  --port-security-enabled=False

or

openstack port set --disable-port-security 

>
> 09.03.2017 03:18, Sterdnot Shaken пишет:
>>
>> Is there a way to disable Mac and IP spoof protection for just 1 instance?
>>
>>
>> I want to run an L2TP server on that instance so I can merge a remote
>> (over the internet) broadcast domain at a customer site with a Openstack
>> tenant network. To do this though, I need Openstack to allow n number of
>> MAC addresses and IP's to be allowed out the instances port, which
>> IP/MAC spoofing is preventing...
>>
>>
>> Any ideas?
>>
>>
>> Thanks in advance!!
>>
>>
>>
>> ___
>> 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

[openstack-dev] [nova][docs] Broken nova instructions

[Alexandra Settle]

Hi everyone,

The installation guide for docs.o.o is currently broken and requires immediate 
attention from the doc and nova teams.

I have moved the relevant bug[0] to be CRITICAL at request. Brian Moss (bmoss) 
and Amy Marrich (spotz) have been working on a subsequent patch for the last 10 
days without result; the current instruction set still do not enable the user 
to start up an instance. There is another Red Hat bug tracking the issue for 
RDO.[1]

Any and all reviews on the patch[2] would be appreciated. We need to be able to 
branch

Thank you,

Alex

[0] https://bugs.launchpad.net/openstack-manuals/+bug/1663485
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1405098
[2] https://review.openstack.org/#/c/438328/


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

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Vikash Kumar]

Tried on Ubuntu 16.04, its fine.

On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar <
vikash.ku...@oneconvergence.com> wrote:

> Import path looks OK
> https://github.com/openstack/networking-sfc/blob/master/
> networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23
>
>
> Are u suggesting something else?
>
> On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton  wrote:
>
>> That location was recently changed in the Neutron side.[1] It sounds like
>> sfc has to be updated.
>>
>> 1. https://github.com/openstack/neutron/commit/4ec456d31501f
>> 09c68b5c23c488878da32dce75e
>>
>> On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar <
>> vikash.ku...@oneconvergence.com> wrote:
>>
>>> Hi Igor,
>>>
>>>This is weird. I just did a fresh clone and executed *"tox" *command.
>>> I am getting same error. Am I missing anything here ? There is no private
>>> change here.  Below is the link for entire log.
>>>
>>>  http://paste.openstack.org/show/601870/
>>>
>>> On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor <
>>> igor.duarte.card...@intel.com> wrote:
>>>
 Hi Vikash,

 Please stick to pastebin for complete logs.



 Check your migration files:



 FAILED: Contract HEAD file does not match migration timeline head,
 expected: 48072cb59133



 Best regards,

 Igor.



 *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
 *Sent:* Tuesday, March 7, 2017 5:03 PM
 *To:* openstack-dev 
 *Subject:* Re: [openstack-dev] [networking-sfc] patch test failed due
 to "import error: vlanmanager"



 Complete log:

  py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
 py35 installdeps: -r/home/vikash/guess_vk/python
 -dev/networking-sfc/requirements.txt, -r/home/vikash/guess_vk/python
 -dev/networking-sfc/test-requirements.txt
 py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
 py35 installed: /home/vikash/guess_vk/python-d
 ev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated,  f = open(fullname,
 "rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==
 0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulso
 up4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==
 0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2
 ,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,du
 lwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.
 14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenle
 t==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,ima
 gesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,
 jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,
 keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,
 logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSa
 fe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.
 20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e git+
 https://github.com/openstack/networking-sfc.git@c51052e3
 748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e git+
 https://github.com/openstack/neutron.git@41be555eddb0f99
 47fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,ope
 nstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.
 0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,os
 lo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.1
 2.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.
 messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.
 0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serializa
 tion==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.
 versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==
 2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.
 0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,
 pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable=
 =0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.
 5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,
 pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==
 2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,
 python-designateclient==2.6.0,python-editor==1.0.3,python-
 glanceclient==2.6.0,python-keystoneclient==3.10.0,python-
 mimeparse==1.6.0,python-neutronclient==6.1.0,python-
 novaclient==7.1.0,python-openstackclient==3.8.1,python-
 subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,repoz
 e.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requestse
 xceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,Routes==2.
 4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,snowballstemm
 er==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,sqlalchemy-migrat
 e==0.11.0,sqlparse==0.2.3,statsd==3.2.1,stevedore==1.21.
 

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

[Alfredo Moralejo Alonso]

On Wed, Mar 8, 2017 at 12:44 PM, Steven Hardy  wrote:
> Hi all,
>
> I wanted to raise visibility of a problem we're experiencing in TripleO CI,
> which I think will potentially affect other projects that consume trunk
> builds from the RDO repositories (and potentially other distros too I
> guess)
>
> The problem is that we tag our final ocata releases after branching
> stable/ocata, but there is then a period prior to cutting pike-1 milestone
> releases (or some other intermediate release for projects not following the
> milestone model) where trunk package builds n-v-r is older than the stable
> branches.
>
> This presents a big problem if you want to test package-derived updates
> from stable/$foo to master, as the pacakges don't get updated where the
> installed stable one is newer than the one built from master.
>
> I raised this bug initially thinking it was specific to the puppet-*
> projects, but it seems from subsequent discussion that it's a broader issue
> that may impact many OpenStack projects.
>
> https://bugs.launchpad.net/tripleo/+bug/1669462
>
> I'm not clear on the best path forward at this point, but the simplest one
> suggested so far is to simply tag a new pre-milestone/alpha release for all
> master branches, which will enable testing upgrades to master.
>

As reference, puppet team proposed a solution for this issue in
openstack puppet modules in
http://lists.openstack.org/pipermail/openstack-dev/2017-March/113494.html

However, as mentioned before this is affecting all projects, not only
puppet ones.

> I know we don't expect to fully support upgrades to pre-milestone releases,
> but the requirement here is to simply enable testing them.
>
> A side-benefit of this regular testing e.g via CI is we'll find upgrade issues
> much faster than waiting for one or more milestone releases to happen then
> doing an upgrade-debug firedrill later in the cycle (which has been bad for
> project and deployment teams IMO, so it'd be good to figure out this first
> step to enable earlier testing of upgrades to the development release).
>
> Any thoughts on how we can resolve this would be much appreciated, thanks!
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Adam Heczko]

My 2c: agreed with everything Kevin said. IMO OpenStack is currently open
source IaaS implementation and there's nothing wrong with this. For cloud
native apps COE makes more sense and these platforms are maturing rapidly.
The way OpenStack should evolve is to make consumption and coexistence of
virtualized workloads with COE workloads straightforward.
In regards to Application Catalog if OpenStack infra is not appropriate
place for its hosting purposes maybe moving it to Github or similar hosting
service should be considered.


On Wed, Mar 8, 2017 at 6:42 PM, Fox, Kevin M  wrote:

> For the OpenStack Applications Catalog to be successful in its mission, it
> required other parts of OpenStack to consider the use case a priority. Over
> the years it became quite clear to me that a significant part of the
> OpenStack community does not want OpenStack to become a place where cloud
> native applications would be built/packaged/provided to users using
> OpenStacks apis but instead just a place to run virtual machines on which
> you might deploy a cloud native platform to handle that use case. As time
> goes on, and COE's gain multitenancy, I see a big contraction in the number
> of OpenStack deployments or deployed node count and a shifting of OpenStack
> based workloads more towards managing pet vm's, as the cloud native stuff
> moves more and more towards containers/COE's which don't actually need vm's.
>
> This I think will bring the issue to a head in the OpenStack community
> soon. What is OpenStack? Is it purely an IaaS implementation? Its pretty
> good at that now. But something that will be very niche soon I think. Is it
> an Cloud Operating system? The community seems to have made that a
> resounding no. Is it an OpenSource competitor to AWS? Today, its getting
> further and further behind in that. If nothing changes, that will be
> impossible.
>
> My 2 cents? I think the world does need an OpenSource implementation of
> what AWS provides. That can't happen on the path we're all going down now.
> We're struggling with division of vision between the two ideologies and
> lack of decision around a COE, causing us to spend a huge amount of effort
> on things like Trove/Sahara/etc to reproduce functionality in AWS, but not
> being as agile as AWS so we can't ever make headway. If we want to be an
> OpenSource AWS competitor, that requires us to make some hard calls, pick a
> COE (Kubernetes has won that space I believe), start integrating it
> quickly, and retool advanced services like Trove/Sahara/etc to target the
> COE rather then VM's for deployment. This should greatly enhance our
> ability to produce functional solutions quickly.
>
> But, its ultimately the Community who decide what OpenStack will become.
> If we're ok with the path its headed down, to basically just be an IaaS,
> that's fine with me. I'd just like it to be a conscious decision rather
> then one that just happens. If thats the way it goes, lets just decide on
> it now, and let the folks that are spinning their wheels move on to a
> system that will help them make headway in their goals. It will be better
> for everyone.
>
> Thanks,
> Kevin
>
> 
> From: David Moreau Simard [d...@redhat.com]
> Sent: Wednesday, March 08, 2017 8:23 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog
>
> The App Catalog, to me, sounds sort of like a weird message that
> OpenStack somehow requires applications to be
> packaged/installed/deployed differently.
> If anything, perhaps we should spend more effort on advertising that
> OpenStack provides bare metal or virtual compute resources and that
> apps will work just like any other places.
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Wed, Mar 8, 2017 at 9:41 AM, Jay Pipes  wrote:
> > On 03/06/2017 06:26 AM, Thierry Carrez wrote:
> >>
> >> Hello everyone,
> >>
> >> The App Catalog was created early 2015 as a marketplace of pre-packaged
> >> applications that you can deploy using Murano. Initially a demo by
> >> Mirantis, it was converted into an open upstream project team, and
> >> deployed as a "beta" as apps.openstack.org.
> >>
> >> Since then it grew additional categories (Glance images, Heat & Tosca
> >> templates), but otherwise did not pick up a lot of steam. The website
> >> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> >> heat templates and 94 murano packages (~30% of which are just thin
> >> wrappers around Docker containers). Traffic stats show around 100 visits
> >> per week, 75% of which only read the index page.
> >>
> >> In parallel, Docker developed a pretty successful containerized
> >> application marketplace (the Docker Hub), with hundreds of thousands of
> >> regularly-updated apps. Keeping the App Catalog around (including