Re: [openstack-dev] [horizon][neutron][lbaas] Horizon support for neutron-lbaas v2

[Akihiro Motoki]

Hi Vivek and LBaaS folks,

I added [horizon] tag so that Horizon folks can be aware of this thread.

Before jumping into LBaaS specific topic, let me share the current effort
As you may know, Horizon team itself is exploring a way how to make
development of each panel fast and smooth.

- One example is a separate repository like designate-dashboard as I
mentioned in the last mail.
  This kind of repositories can be maintained by both the horizon team and
the service team (designate-core for designate-dashboard).
- Another example is 'contrib' directory in the horizon main repository.
Sahara dashboard is being moved to contrib directory now.
  It is done by the same motivation as the first example. Honestly I don't
fully understand how it works (subdirectory core reviewers).
  I think David, Horizon PTL, can explain more detail.
- Of course, we have third option as you mentioned: a dedicated directory
under neutron-lbaas repository.

If we would like to maintain LBaaS dashboard repository separately for long
term,
First two options look good to me because Horizon developers are easy to
find a repository.

Now I return to LBaaS related topic
I think we need to consider this from two perspective: technical
perspective and release management perspective.

Technically I don't see a problem so far.
As far as I check LBaaS v1 dashboard, there is no references from outside
of LBaaS panel
so we can easily move it to a separate place.
One exception is Floating IP panel. It is aware of Load balancer VIP port.
Horizon does not
have a way to customize existing forms at now, so we can need to change
codes in Horizon
repo for such case, but I think it is a special case and I hope it is not a
burden.

>From the release management and consumer perspective,
If we move LBaaS dashboard to some other place, users need to install it
separately
though they don't need to do more previously. It may be a big problem but
we need
to keep it in my mind.
Another thing is how to manage the release process.
Who is responsible for the release, Neutron or Horizon?

I don't have strong opinion on choices.
I would like to hear David's opinion. I will ask him to join the discussion.

Thanks,
Akihiro

2015-07-15 2:22 GMT+09:00 Jain, Vivek :

>  Thanks Akihiro. Currently lbaas panels are part of horizon repo. If
> there is a easy way to de-couple lbaas dashboard from horizon? I think that
> will simplify development efforts. What does it take to separate lbaas
> dashboard from horizon?
>
>  Thanks,
> Vivek
>
>   From: Akihiro Motoki 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, July 14, 2015 at 10:09 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Cc: "Balle, Susanne" , "Tonse, Milan" <
> mto...@ebay.com>
>
> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
> neutron-lbaas v2
>
>   Another option is to create a project under openstack.
> designate-dashboard project takes this approach,
> and the core team of the project is both horizon-core and designate-core.
> We can do the similar approach. Thought?
>
>  I have one question.
> Do we have a separate place forever or do we want to merge horizon repo
> once the implementation are available.
> If we have a separate repo for LBaaS v2 panel, we need to release it
> separately.
>
>  I am not sure I am available at LBaaS meeting, but I would like to help
> this efforts as a core from horizon and neutron.
>
>  Akihiro
>
>
> 2015-07-15 1:52 GMT+09:00 Doug Wiegley :
>
>> I’d be good submitting it to the neutron-lbaas repo, under a horizon/
>> directory. We can iterate there, and talk with the Horizon team about how
>> best to integrate. Would that work?
>>
>> Thanks,
>> doug
>>
>> > On Jul 13, 2015, at 3:05 PM, Jain, Vivek  wrote:
>> >
>> > Hi German,
>> >
>> > We integrated UI with LBaaS v2 GET APIs. We have created all panels for
>> > CREATE and UPDATE as well.
>> > Plan is to share our code with community on stackforge for more
>> > collaboration from the community.
>> >
>> > So far Ganesh from cisco has shown interest in helping with some work.
>> It
>> > will be great if we can get more hands.
>> >
>> > Q: what is the process for hosting in-progress project on stackforge?
>> Can
>> > someone help me here?
>> >
>> > Thanks,
>> > Vivek
>> >
>> > On 7/10/15, 11:40 AM, "Eichberger, German" 
>> > wrote:
>> >
>> >> Hi Vivek,
>> >>
>> >> Hope things are well. With the Midccyle next week I am wondering if you
>> >> made any progress and/or how we can best help with the panels.
>> >>
>> >> Thanks,
>> >> German
>> >>
>> >> From: "Jain, Vivek" mailto:vivekj...@ebay.com>>
>> >> Reply-To: "OpenStack Development Mailing List (not for usage
>> questions)"
>> >> > openstack-...@lists.openstack.or
>> >> g>>
>> >> Date: Wednesday, April 8, 2015 at 3:32 PM
>> >> To: "OpenStack Development Mailing List (not for usage questions)"
>> >> > openstack-...@l

Re: [openstack-dev] [Senlin] TOSCA Reference Material

[Qiming Teng]

Thanks, Julio, for sharing this.

Regards,
  Qiming
On Tue, Jul 14, 2015 at 12:08:39PM -0500, Julio E Ruano wrote:
> Hi All,
> 
> I just wanted to share where all of the TOSCA reference material is 
> accessible. It is maintained through an OASIS TC here -> 
> https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca 
> 
> The latest relevant spec is available here -> 
> https://www.oasis-open.org/committees/download.php/56070/TOSCA-Simple-Profile-YAML-v1.0-wd06-rev05.docx
>  
> 
> 
> Of immediate synergy with Senlin is probably the discussion around 
> policies starting on page #240 of the spec. Much of this is still in the 
> definition stage, so there is opportunity to have Senlin influence the 
> spec as well as to allow Senlin to adopt some of the definitions within 
> the spec.
> 
> Regards,
> 
> - Julio

> __
> OpenStack Development Mailing List (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] [swift] [ceilometer] Ceilometer log dir permissions bust swift proxy

[Mark Kirkwood]

On 14/07/15 11:05, Mark Kirkwood wrote:

On 13/07/15 06:44, Emilien Macchi wrote:




Yeah, I guess I should raise a bug with Ubuntu so it (maybe) gets sorted
out. However in the meantime we may have to work around it by amending
the dir permissions in puppet (the alternative - rolling our own
packages is undesirable in general). However I note there are also
python version mistakes in the ceilometer requires.txt which need
patching (sigh).



For completeness, with reference to that last point the latest 
(2015.1.5) releases for ceilometer on Ubuntu 14.04 seem to have 
corrected the requires.txt (which is great).


Regards

Mark


__
OpenStack Development Mailing List (not 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] - Proposing Miguel Angel Ajo for the Control Plane core team

[Somanchi Trinath]

Congratulations Miguel :-)


-Original Message-
From: Miguel Angel Ajo [mailto:mangel...@redhat.com] 
Sent: Tuesday, July 14, 2015 7:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the 
Control Plane core team

Thanks Kevin and everybody for the positive feedback! :)

It's a pleasure to work with so many awesome people.

Best,
Miguel Ángel,



Kevin Benton wrote:
> It's been a week with no negative feedback. Welcome to the team Miguel!
> On Jul 7, 2015 5:22 AM, "Ihar Hrachyshka"  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Oh yes!
>>
>> It was a bit weird that Miguel, while owning a feature branch, did 
>> not have a say in what is merged there. Now it should be more in line 
>> with his actual position in the project.
>>
>> Good work, Miguel!
>>
>> On 07/06/2015 01:02 PM, Kevin Benton wrote:
>>> Hello!
>>>
>>> As the Lieutenant of the built-in control plane[1], I am proposing 
>>> to add Miguel Angel Ajo to the control plane core reviewer team.
>>>
>>> His review stats are inline with the other core reviewers[2], and 
>>> his work on improving the stability/performance of the agents over 
>>> the last year has been important in making the reference 
>>> implementation reliable.
>>>
>>> Existing cores, please vote +1/-1 for his addition to the team.
>>>
>>> Cheers!
>>>
>>> 1.
>>> http://docs.openstack.org/developer/neutron/policies/core-reviewers.
>>> ht
>> ml
>> 2. http://stackalytics.com/report/contribution/neutron/30
>> http://stackalytics.com/report/contribution/neutron/60
>> http://stackalytics.com/report/contribution/neutron/90
>>> -- Kevin Benton
>>>
>>>
>>>
>>> 
>>> __
>> 
>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQEcBAEBCAAGBQJVm7WcAAoJEC5aWaUY1u57RUoH/jIimjwrLqzzq8u0Ix25YGrR
>> CQVkLGbE7j+LtzvKOcFSORp/Y/gwsJ6KF3B7NBqfh1C0fHx/uMVp/tf7/NhuthE0
>> 7+gsMe3yn6oOraYCQHwEDHpxz6r+7dmMfhisknH5k7vsdnwNi5CrnXyr+knxrQ0L
>> jjFvdi3F/+2ztV5LtPJLPoU72d81ATwEEFTH/9vUeFPlBu8okUuXRszPJCWR3MeL
>> PrKeg5G6OH4b4GVC45Q7238rWB7uiwfFLILo9I8qwgJ/LZnKkK12bmk3tUgE3cqP
>> BXxfuMKueJgOvRU0VPpWZwXicf2/pOmdUBv7uX+BeK9hPP5G9i8ITmFblB+doUk=
>> =EuZs
>> -END PGP SIGNATURE-
>>
>> _
>> _ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

[Daniel Comnea]

Can i understand the use case for that?

What i don't get it is how will you know the MAC for a new created instance
via HEAT so you can set at the same time the SG based on MAC?



On Tue, Jul 14, 2015 at 12:29 PM, yan_xing...@163.com 
wrote:

> Thank you, Kevin.
> I search the blueprint about this point in launchpad.net
> , and got nothing, then register one at:
> https://blueprints.launchpad.net/neutron/+spec/security-group-mac-rule
>
>
> --
> Yan Xing'an
>
>
> *From:* Kevin Benton 
> *Date:* 2015-07-14 18:31
> *To:* OpenStack Development Mailing List (not for usage questions)
> 
> *Subject:* Re: [openstack-dev] [neutron][security-group] rules for filter
> mac-addresses
> Unfortunately the security groups API does not have mac-level rules right
> now.
>
> On Tue, Jul 14, 2015 at 2:17 AM, yan_xing...@163.com 
> wrote:
>
>> Hi, all:
>>
>> Here is a requirement: deny/permit incoming packets on VM by mac
>> addresses,
>> I have tried to find better method than modifying neutron code, but
>> failed.
>> Any suggesion is grateful. Thank you.
>>
>> Yan.
>>
>> --
>> yan_xing...@163.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Kevin Benton
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not 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] A new BP - Support large datasets being passed

[Renat Akhmerov]

Moshe, thanks for addressing this.

I think we need to implement this BP in this cycle (actually asap) as I think 
it can potentially create problems with real usage now. So I fully support it. 
One thing we need to do is to see what other columns (besides listed out in BP) 
should also be transformed.


Renat Akhmerov
@ Mirantis Inc.



> On 14 Jul 2015, at 23:42, ELISHA, Moshe (Moshe) 
>  wrote:
> 
> Hey,
>  
> I have created a new BP “Support large datasets being passed” [1].
> You comments / suggestion / approval are most welcome.
>  
> [1] - https://blueprints.launchpad.net/mistral/+spec/support-large-datasets 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

[Manickam, Kanagaraj]

Like to share my opinions as below:

Resource-type-list/resource-type-show:
Once the role based resource exposure is enabled, based on the user's 
role, I believe, (s)he would expect to see those deployed resource-types, which 
are authorized. And wanted to know if that resource-type is available currently 
on that cloud. So by default, it will essentially filter out those 
un-authorized resource-types from the users, but it will provide the additional 
information, whether resource-type is currently available or not. (admin has 
access to all resource-types). And resource-type-list could be enhanced further 
with additional filtering flag like :

'---show-authorized': default behavior
'--show-unavailable': list those authorized un-available resource-types
 '--show-available': list those authorized available resource-types
'--show-unauthorized': This may be wrong one, I too believe. But like to get 
others opinion on it. It list all the deployed resource-types, which are 
un-authorized. It  becomes like live resource-type documents from running heat 
service. (other place user may want to know the same details from the public 
resource-type document available in the internet) . But here, operators may 
want to disable to report the un-authorized resource-types to those user, who 
does not have right roles. So we could provide config parameter for the same. 
I'm not sure on it though !

Template-validate:
As it really helps user to validate the template, before starting the 
stack creation, it would be better to validate complete template and report all 
the errors in the template, which includes the unavailability of the service in 
the service catalog, authorization check as well. Currently, template-validate 
exit on the occurrence of first error in the template. (I'm working on it)

Regards
Kanagaraj M


-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com] 
Sent: Wednesday, July 15, 2015 1:05 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] conditional resource exposure - second 
thoughts

On 14/07/15 14:34, Pavlo Shchelokovskyy wrote:
> Hi Heaters,
>
> currently we already expose to the user only resources for services 
> deployed in the cloud [1], and soon we will do the same based on 
> whether actual user roles allow creating specific resources [2]. Here 
> I would like to get your opinion on some of my thoughts regarding 
> behavior of resource-type-list, resource-type-show and 
> template-validate with this new features.
>
> resource-type-list
> We already (or soon will) hide unavailable in the cloud / for the user 
> resources from the listing. But what if we add an API flag e.g. --all 
> to show all registered in the engine resources? That would give any 
> user a glimpse of what their Orchestration service can manage in 
> principle, so they can nag the cloud operator to install additional 
> OpenStack components or give them required roles :)

I worry that this could result in leakage of potentially-sensitive information. 
e.g. once we have this feature implemented, an operator could deploy a plugin 
that is only for the use of one particular user, who has a custom role. I don't 
think it would be expected that other users (without that role) in other 
tenants could find out about that, even if all they can find out is the name of 
the resource type.

I definitely think that admins should have a way of getting a list of _all_ 
resource types (preferably annotated with the roles required to use them). Just 
not ordinary users.

> resource-type-show
> Right now the plan is to disable "showing" unavailable to the user 
> resources. But may be we should leave this as it is, for the same 
> purpose as above (or again add a --all flag or such)?

This is totally unnecessary IMHO for the reasons Clint mentioned. Again, I 
could imagine an exception for admins though, since I suspect that this API is 
the only way we can annotate resource types with the roles required without 
performing major surgery on resource-type-list.

> template-validate
> Right now Heat is failing validation for templates containing resource 
> types not registered in the engine (e.g. typo). Should we also make 
> this call available services- and roles-sensitive? Or should we leave 
> a way for a user to check validity of any template with any in 
> principle supported resources?

You call template-validate when you're about to launch the template and you 
want to know what parameters and stuff are required. If YOU cannot launch THIS 
template on THIS cloud right NOW it should fail, period.

cheers,
Zane.

> The bottom line is we are good in making Heat service to be as much 
> self-documented via its own API as possible - let's keep doing that 
> and make any Heat deployment to be the Heat primer :)
>
> Eager to hear your opinions.
>
> [1]
> http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditio
> nal-resource-exposure-services.html
>
> [2]
> http

Re: [openstack-dev] [testing] moving testrepository *outside* the tox venv

[Robert Collins]

On 13 July 2015 at 06:19, Mike Bayer  wrote:
>
>
> On 7/11/15 6:04 AM, Robert Collins wrote:
>>
>> Wearing my upstream hat, testr is *still* intended to be used differently
>> than OpenStack is doing. Running all the tests for all python versions at
>> once in parallel is the sort of thing testr is aimed at, and thats fairly
>> fundamentally incompatible with running from inside a venv. As is
>> distributed testing across multiple machines. I haven't had time to help
>> OpenStack mature its use of testr until recently, and fixing these issues
>> that are and will have seems pretty important to me.
>
>
> this is totally a peanut gallery comment, as I haven't carefully read this
> whole thread, but doesn't this mean that the use of testr *and* tox at the
> same time is fundamentally wrong?   Because tox's main purpose is to
> facilitate running tests in multiple environments (though not simultaneously
> / distributed).  If testr already does that, why are we using tox?  (other
> than the IMO fairly obvious, "it's used ubiquitously, is popular, and
> everyone knows how to use it" argument).

It's a totally reasonable question and the answer is that they are
complementary.
tox is Python specific.

testr is not.

testr doesn't want to learn about making sdists, for instance :).

So use tox to setup a given virtualenv, and testr to run the tests
within that. I think that testr wants to orchestrate that, eventually.

For now, all we need to do (AFAICT) is:

a - get testr installed on the infra images
b - update the developer docs to also instruct folk to install testr
c - stop using the (ugh, it was a mistake) setup.py glue that runs testr
d - remove testrepository from everyone's test-requirements.txt

step c) is likely to uncover one or more missing integration points in
testr, which we'll fix promptly.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

[openstack-dev] 答复: [Heat] conditional resource exposure - second thoughts

[Huangtianhua]

-邮件原件-
发件人: Zane Bitter [mailto:zbit...@redhat.com] 
发送时间: 2015年7月15日 3:35
收件人: openstack-dev@lists.openstack.org
主题: Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

On 14/07/15 14:34, Pavlo Shchelokovskyy wrote:
> Hi Heaters,
>
> currently we already expose to the user only resources for services 
> deployed in the cloud [1], and soon we will do the same based on 
> whether actual user roles allow creating specific resources [2]. Here 
> I would like to get your opinion on some of my thoughts regarding 
> behavior of resource-type-list, resource-type-show and 
> template-validate with this new features.
>
> resource-type-list
> We already (or soon will) hide unavailable in the cloud / for the user 
> resources from the listing. But what if we add an API flag e.g. --all 
> to show all registered in the engine resources? That would give any 
> user a glimpse of what their Orchestration service can manage in 
> principle, so they can nag the cloud operator to install additional 
> OpenStack components or give them required roles :)

I'd agree with Zane. Only allow admins to getting all resource types not 
ordinary users.

> resource-type-show
> Right now the plan is to disable "showing" unavailable to the user 
> resources. But may be we should leave this as it is, for the same 
> purpose as above (or again add a --all flag or such)?

I'd prefer to allow admins to show all resource type. The behavior should be 
consistent, ordinary users can only show the resource type which they can list. 

> template-validate
> Right now Heat is failing validation for templates containing resource 
> types not registered in the engine (e.g. typo). Should we also make 
> this call available services- and roles-sensitive? Or should we leave 
> a way for a user to check validity of any template with any in 
> principle supported resources?

I'd agree with Zane. And I think if we can give the detail reasons(service 
unavailable or resources type is not supported) why the validation is failed 
will be good to users.

cheers,
Zane.

> The bottom line is we are good in making Heat service to be as much 
> self-documented via its own API as possible - let's keep doing that 
> and make any Heat deployment to be the Heat primer :)
>
> Eager to hear your opinions.
>
> [1]
> http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditio
> nal-resource-exposure-services.html
>
> [2]
> http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditio
> nal-resource-exposure-roles.html
>
> Best regards,
>
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


__
OpenStack Development Mailing List (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] [magnum] Magnum template manage use platform VS others as a type?

[Adrian Otto]

One drawback to virt_type if not seen in the context of the acceptable values, 
is that it should be set to values like libvirt, xen, ironic, etc. That might 
actually be good. Instead of using the values 'vm' or 'baremetal', we use the 
name of the nova virt driver, and interpret those to be vm or baremetal types. 
So if I set the value to 'xen', I know the nova instance type is a vm, and 
'ironic' means a baremetal nova instance.

Adrian


 Original message 
From: Hongbin Lu 
Date: 07/14/2015 7:20 PM (GMT-08:00)
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [magnum] Magnum template manage use platform VS 
others as a type?

I am going to propose a third option:

3. virt_type

I have concerns about option 1 and 2, because “instance_type” and flavor was 
used interchangeably before [1]. If we use “instance_type” to indicate “vm” or 
“baremetal”, it may cause confusions.

[1] https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup

Best regards,
Hongbin

From: Kai Qiang Wu [mailto:wk...@cn.ibm.com]
Sent: July-14-15 9:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum] Magnum template manage use platform VS others 
as a type?


Hi Magnum Guys,


I want to raise this question through ML.


In this patch https://review.openstack.org/#/c/200401/


For some old history reason, we use platform to indicate 'vm' or 'baremetal'.
This seems not proper for that, @Adrian proposed nova_instance_type, and 
someone prefer other names, let me summarize as below:


1. nova_instance_type  2 votes

2. instance_type 2 votes

3. others (1 vote, but not proposed any name)


Let's try to reach the agreement ASAP. I think count the final votes winner as 
the proper name is the best solution(considering community diversity).


BTW, If you not proposed any better name, just vote to disagree all, I think 
that vote is not valid and not helpful to solve the issue.


Please help to vote for that name.


Thanks




Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

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

Re: [openstack-dev] [Congress] New IRC meeting time

[Masahito MUROI]

I'm happy to see that.

btw, is the day on Tuesday?

best regard,
masa

On 2015/07/15 9:52, Zhou, Zhenzan wrote:

Glad to see this change.
Thanks for the supporting for developers in Asia☺

BR
Zhou Zhenzan

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Wednesday, July 15, 2015 02:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] New IRC meeting time

To better accommodate the active contributors, we're moving our IRC meeting to

2300 UTC = 4p Pacific = 7p Eastern
#openstack-meeting-3

Hope to see you there!
Tim



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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


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

Re: [openstack-dev] [magnum] Magnum template manage use platform VS others as a type?

[Hongbin Lu]

I am going to propose a third option:

3. virt_type

I have concerns about option 1 and 2, because “instance_type” and flavor was 
used interchangeably before [1]. If we use “instance_type” to indicate “vm” or 
“baremetal”, it may cause confusions.

[1] https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup

Best regards,
Hongbin

From: Kai Qiang Wu [mailto:wk...@cn.ibm.com]
Sent: July-14-15 9:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum] Magnum template manage use platform VS others 
as a type?


Hi Magnum Guys,


I want to raise this question through ML.


In this patch https://review.openstack.org/#/c/200401/


For some old history reason, we use platform to indicate 'vm' or 'baremetal'.
This seems not proper for that, @Adrian proposed nova_instance_type, and 
someone prefer other names, let me summarize as below:


1. nova_instance_type  2 votes

2. instance_type 2 votes

3. others (1 vote, but not proposed any name)


Let's try to reach the agreement ASAP. I think count the final votes winner as 
the proper name is the best solution(considering community diversity).


BTW, If you not proposed any better name, just vote to disagree all, I think 
that vote is not valid and not helpful to solve the issue.


Please help to vote for that name.


Thanks




Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193

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

[openstack-dev] [Nova] Virtual device role tagging

[Artom Lifshitz]

Hello,

I'd like to get the conversation started around a spec that my colleague Dan
Berrange has proposed to the backlog.

The spec [1] solves the problem of passing information about virtual devices
into an instance.

For example, in an instance with multiple network interfaces, each connected to
profoundly different networks, software running inside the instance needs to
know each NIC's role. Similarly, in an instance with multiple disks, each
intended for different a usage, software inside the instance needs to know each
disk's role.

I feel like a lot of discussion will happen around this spec before it can
be merged - hopefully in the M cycle - so I'm requesting comments and
suggestions very early ;)

Thanks all!

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

__
OpenStack Development Mailing List (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] [magnum] Magnum template manage use platform VS others as a type?

[Kai Qiang Wu]

Hi Magnum Guys,


I want to raise this question through ML.


In this patch https://review.openstack.org/#/c/200401/


For some old history reason, we use platform to indicate 'vm' or
'baremetal'.
This seems not proper for that, @Adrian proposed nova_instance_type, and
someone prefer other names, let me summarize as below:


1. nova_instance_type  2 votes

2. instance_type 2 votes

3. others (1 vote, but not proposed any name)


Let's try to reach the agreement ASAP. I think count the final votes winner
as the proper name is the best solution(considering community diversity).


BTW, If you not proposed any better name, just vote to disagree all, I
think that vote is not valid and not helpful to solve the issue.


Please help to vote for that name.


Thanks




Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

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

Re: [openstack-dev] [Congress] New IRC meeting time

[Zhou, Zhenzan]

Glad to see this change.
Thanks for the supporting for developers in Asia☺

BR
Zhou Zhenzan

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Wednesday, July 15, 2015 02:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] New IRC meeting time

To better accommodate the active contributors, we're moving our IRC meeting to

2300 UTC = 4p Pacific = 7p Eastern
#openstack-meeting-3

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

Re: [openstack-dev] [Fuel] Being spammed by bugs when assigned to whole fuel team

[Mike Scherbakov]

Thank you. I think I resolved this with new filter matching exact "You
received this bug notification because you are a member of". If I'm
subscribed directly to the bug, there is another message is used by LP like
"You received this bug notification because you are subscribed to the bug
report.
*https://bugs .*launchpad*.net/bugs/1474120"*


On Tue, Jul 7, 2015 at 1:56 PM Aleksandra Fedorova 
wrote:

> Hi, Mike,
>
> let me post a quote from #launchpad IRC chat:
>
>bookwar: hi all, is there any permission setting which forbids
> subscribing someone to the bug? As i see it, one can easily spam a
> group by subscribing it to a certain bug. How we can prevent this?
>mgz: ban the person doing the spamming?
>mgz: launchpad assumes its users are generally sane, but has
> recourse if that turns out to not be the case
>
> This quote is about 1.5 year old, but i guess the idea is still the same.
>
>
> As a possible workaround it should be possible to set main filters to
> filter out less common mail headers, for example:
>
>X-Launchpad-Message-Rationale: Assignee @fuel-dev
>
> See [1] for details.
>
> [1] https://help.launchpad.net/Bugs/Subscriptions
>
> On Tue, Jul 7, 2015 at 11:27 PM, Mike Scherbakov
>  wrote:
> > Hi folks,
> > DevOps guys - when someone assigns bug to "Fuel for OpenStack", message
> is
> > being sent to 120 people.
> >
> > Is there a way to restrict such assignment in Launchpad? I want to only
> > allow fuel-python, and other subteams available. Or do something with LP
> > groups.
> >
> > The problem is that I'm getting tired of many (not relevant to me) bugs
> > flowing in my inbox, and stop paying attention. I'll have to create
> filter.
> > And if someone needs my attention in particular bug, subscribes me to it
> -
> > I'll miss it, as it will be filtered by the same way.
> >
> > Thank you,
> > --
> > Mike Scherbakov
> > #mihgen
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Aleksandra Fedorova
> Fuel Devops Engineer
> bookwar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Fox, Kevin M]

Yeah. Sounds reasonable. I just wanted to raise the discussion since one might 
affect the implementation of the other. 

In fact, thinking through it more, having the validate template api be 
restricted to just what the specific instance of heat can do actually might 
help play a part in the solution to the other issue.

If you go look at the template in the app catalog ui in horizon, it could call 
out to heat template validate at that point and let you know if its supported 
or not by your specific cloud. If it validated for all clouds, that wouldn't be 
an option.

Though there is another issue the catalog will eventually hit where we would 
like to have a repo of contributed templates that we can do some automated 
tests to ensure they either work or at least validate. The --all flag would 
probably help with that case. In the test environment, we might not be able to 
test against some advanced services but could at least tell if it was a valid 
template.

Thanks,
Kevin

From: Randall Burt [randall.b...@rackspace.com]
Sent: Tuesday, July 14, 2015 3:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure 
- secondthoughts

A feedback mechanism for users is obviously a "good thing", but IMO, not 
germane to the threads original purpose of how and when to expose supported 
resources in Heat. I cannot imagine us implementing such a feature directly.

This may be a good discussion to have in the context of app catalog exclusively 
and not in the context of Heat since we seem to be discussing a generally 
available catalog vs Heat running in a specific environment. These two issues 
are quite different in terms of "what's supported".

In the Heat case, the documentation in OpenStack is "good enough" IMO for "what 
are all the things Heat can possibly let me do" while the chosen endpoint is 
the place to answer "what are the things *this* installation of Heat will let 
me do". If the answer to the latter is unsatisfactory, then the user should 
already have mechanisms to encourage the operator to provide what's missing.

On Jul 14, 2015, at 5:31 PM, "Fox, Kevin M" 
 wrote:

> Without a feedback loop of some kind, how does one solve issues like the 
> following:
>
> * Operator decides users don't need neutron NaaS because its "too complicated 
> and users don't need it" (Seen on the mailing list multiple times)
> * Software developer writes cloud templates that deploys software that needs 
> private networks to work (For example, ElasticSearch)
> * User wants to deploy said software but can't discover a working version.
>
> User is sad because they can't find a working template to do what they want. 
> They either reinvent the wheel, or give up and don't use the cloud for that 
> task.
>
> Being able to close the loop and let the operator easily know the users 
> actually need something they aren't providing gives them the opportunity to 
> fix the issue, benefiting all 3 parties.
>
> Thanks,
> Kevin
>
> 
> From: Randall Burt [randall.b...@rackspace.com]
> Sent: Tuesday, July 14, 2015 2:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource 
> exposure - secondthoughts
>
> Making users complain to admins that may have little to no control over what 
> is and isn't available isn't a healthy strategy for user experience. 
> Purposefully engineering hardship to try and influence operators to "do the 
> right thing" in someone else's opinion sounds pretty counter productive to 
> adoption as well.
>
> FWIW, as a user, I don't want to see things I can't use because it just 
> wastes my time. I agree that the docs are a good place to see "all the 
> things" while querying the service should tell me what's available to me at 
> the time.
>
> On Jul 14, 2015, at 4:20 PM, "Fox, Kevin M" 
> wrote:
>
>> We're kind of debating the same thing for the app catalog. Do we show 
>> templates that don't work on a given cloud since they wont work, potentially 
>> making useful tools hard to discover, or do we view it as an opportunity for 
>> users to complain to their admins that they need X feature in order to do 
>> what they need to do. Last time we talked about it, we were leaning towards 
>> the latter.
>>
>> Maybe a happy middle ground is to have enough smarts in the system to show 
>> the templates, identify what parts won't work, gray out the template but 
>> provide a ui to "notifify the admin" of desire for X to work. That way users 
>> can easily feed back their desires.
>>
>> Thanks,
>> Kevin
>> From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
>> Sent: Tuesday, July 14, 2015 11:34 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Heat] conditional resource exposure - second 
>> 

[openstack-dev] [neutron] Service Chain project IRC meeting agenda

[Cathy Zhang]

Hi everyone,
Below are some items we plan to discuss in the next IRC meeting. Please add 
more topics you would like to discuss if any.
Thanks,
Cathy
* Spec update for addressing new comments, and review
* SFC CLI client and Horizon Client dependency on base Neutron CLI and 
Horizon code
* OVS Driver and OVS support for classifier and SFF. If we decide to go 
for no SFC header with chain ID, then the OVS has to build a forwarding table 
based on 5-tuple or n-tuple for flow identification.
*  ?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Separate repo for Fuel Agent

[Mike Scherbakov]

Thanks Vladimir. Let's ensure to get it done sooner than later (this might
require to be tested in custom ISO..) - we are approaching FF, and I expect
growing queues of patches to land...

On Tue, Jul 14, 2015 at 6:03 AM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> New repository [1] has been created. So, please port all your review
> requests to stackforge/fuel-web related to Fuel Agent to this new
> repository. Currently, I am testing these two patches
> https://review.openstack.org/#/c/200595
> https://review.openstack.org/#/c/200025. If they work, we need to merge
> them and that is it. Review is welcome.
>
>
>
> [1] https://github.com/stackforge/fuel-agent.git
>
> Vladimir Kozhukalov
>
> On Fri, Jul 10, 2015 at 8:14 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Ok, guys.
>>
>> Looks like there are no any objections. At the moment I need to create
>> actual version of upstream repository which is going to be sucked in by
>> OpenStack Infra. Please, be informed that all patches changing
>> fuel-web/fuel_agent that will be merged after this moment will need to be
>> ported into the new fuel-agent repository.
>>
>>
>> Vladimir Kozhukalov
>>
>> On Fri, Jul 10, 2015 at 6:38 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Guys, we are next to moving fuel_agent directory into a separate
>>> repository. Action flow is going to be as follows:
>>>
>>> 1) Create verify jobs on our CI https://review.fuel-infra.org/#/c/9186
>>> (DONE)
>>> 2) Freeze fuel_agent directory in https://github.com/stackforge/fuel-web
>>> (will announce in a separate mail thread). That means we stop merging
>>> patches into master which change fuel_agent directory. Unfortunately, all
>>> review requests need to be re-sent, but it is not going to be very
>>> difficult.
>>> 3) Create temporary upstream repository with fuel_agent/* as a content.
>>> I'm not planning to move 5.x and 6.x branches. Only master. So, all fixes
>>> for 5.x and 6.x will be living in fuel-web.
>>> 4) This upstream repository is going to be sucked in by openstack-infra.
>>> Patch is here https://review.openstack.org/#/c/199178/ (review is
>>> welcome) I don't know how long it is going to take. Will try to poke infra
>>> people to do this today.
>>> 5) Then we need to accept two patches into new fuel-agent repository:
>>>  - rpm spec (extraction from fuel-web/specs/nailgun.spec) (ready, but
>>> there is no review request)
>>>  - run_tests.sh (to run tests) (ready, but there is no review request)
>>>
>>> !!! By this moment there won't be any impact on ISO build process !!!
>>>
>>> 6) Then we need to change two things at the same time (review is welcome)
>>>   - fuel-web/specs/nailgun.spec in order to prevent fuel-agent package
>>> building  https://review.openstack.org/#/c/200595
>>>   - fuel-main so as to introduce new fuel-agent repository into the
>>> build process https://review.openstack.org/#/c/200025
>>>
>>> And good luck to me -)
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Wed, Jul 8, 2015 at 12:53 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 There were some questions from Alexandra Fedorova about independent
 release cycle.

 >according to the configuration [1] Infra team won't be able to do
 >branching or any kind of release management for new repository.

 >Could you please clarify, do we plan to version new repository the
 >same way as we do for main fuel repositories or there going to be
 >separate releases as in python-fuelclient [2]? Who should drive the
 >release process for this repo and how this change will affect Fuel ISO
 >release?

 >[1]
 https://review.openstack.org/#/c/199178/1/gerrit/acls/stackforge/fuel-agent.config,cm
 >[2]
 http://lists.openstack.org/pipermail/openstack-dev/2015-July/068837.html

 IMO all Fuel components should be as much independent as possible with
 highly defined APIs used for their interaction, with their own teams, with
 their own independent release cycles. But we cannot switch to this model
 immediately. For the start, we can just move those components into separate
 repositories, leaving the same access rights and core team as we have for
 fuel-web.

 When Fuel Agent is a separate repository we discuss team. It looks like
 a team leader is the best person to manage releases for a particular
 component. This thread is totally about separation stuff and how to do this
 not breaking anything.



 Vladimir Kozhukalov

 On Wed, Jul 8, 2015 at 12:24 PM, Vladimir Kozhukalov <
 vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> I am going to move Fuel Agent into a separate git repository. The
> thing is that we have quite a few review requests to fuel-web with changes
> for Fuel Agent. The new repository is going to look like this
> https://github.com/kozhukalo

Re: [openstack-dev] [Fuel] New Criteria for UX bugs

[Mike Scherbakov]

Sounds good to start, we can always adjust later if needed. I actually
changed one doc bug priority already using this criteria.

On Fri, Jul 10, 2015 at 5:42 AM Jay Pipes  wrote:

> On 07/09/2015 06:14 PM, Andrew Woodward wrote:
> > We often have bugs which create really poor User eXperience (UX) but our
> > current bug priority criteria prevent nearly all of them from being
> > higher than medium (as they nearly always have workarounds). We need to
> > identify what should qualify as a critical, or high UX defect so that
> > they can receive appropriate attention.
> >
> > We discussed what this may look like on the IRC meeting, the general
> > idea here is that the complexity of effort to work around the UX issue
> > should be related to the priority.
> >
> > Critical: requires massive effort to work around, including [un|under]
> > documented commands and edits to config files
> >
> > High: requires modification of config files, interfaces that users
> > aren't expected to use (ie the API when it's _intended_ to work in the
> > CLI / UI (exclusive of interfaces that are intended to only be available
> > via API) or requires custom node yaml (again except when it should
> > exclusively be available)
> >
> > Medium: Straight forward commands in the CLI
>
> Above criteria look excellent to me, thanks Andrew!
> -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
>
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Randall Burt]

A feedback mechanism for users is obviously a "good thing", but IMO, not 
germane to the threads original purpose of how and when to expose supported 
resources in Heat. I cannot imagine us implementing such a feature directly.

This may be a good discussion to have in the context of app catalog exclusively 
and not in the context of Heat since we seem to be discussing a generally 
available catalog vs Heat running in a specific environment. These two issues 
are quite different in terms of "what's supported". 

In the Heat case, the documentation in OpenStack is "good enough" IMO for "what 
are all the things Heat can possibly let me do" while the chosen endpoint is 
the place to answer "what are the things *this* installation of Heat will let 
me do". If the answer to the latter is unsatisfactory, then the user should 
already have mechanisms to encourage the operator to provide what's missing.

On Jul 14, 2015, at 5:31 PM, "Fox, Kevin M" 
 wrote:

> Without a feedback loop of some kind, how does one solve issues like the 
> following:
> 
> * Operator decides users don't need neutron NaaS because its "too complicated 
> and users don't need it" (Seen on the mailing list multiple times)
> * Software developer writes cloud templates that deploys software that needs 
> private networks to work (For example, ElasticSearch)
> * User wants to deploy said software but can't discover a working version.
> 
> User is sad because they can't find a working template to do what they want. 
> They either reinvent the wheel, or give up and don't use the cloud for that 
> task.
> 
> Being able to close the loop and let the operator easily know the users 
> actually need something they aren't providing gives them the opportunity to 
> fix the issue, benefiting all 3 parties.
> 
> Thanks,
> Kevin
> 
> 
> From: Randall Burt [randall.b...@rackspace.com]
> Sent: Tuesday, July 14, 2015 2:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource 
> exposure - secondthoughts
> 
> Making users complain to admins that may have little to no control over what 
> is and isn't available isn't a healthy strategy for user experience. 
> Purposefully engineering hardship to try and influence operators to "do the 
> right thing" in someone else's opinion sounds pretty counter productive to 
> adoption as well.
> 
> FWIW, as a user, I don't want to see things I can't use because it just 
> wastes my time. I agree that the docs are a good place to see "all the 
> things" while querying the service should tell me what's available to me at 
> the time.
> 
> On Jul 14, 2015, at 4:20 PM, "Fox, Kevin M" 
> wrote:
> 
>> We're kind of debating the same thing for the app catalog. Do we show 
>> templates that don't work on a given cloud since they wont work, potentially 
>> making useful tools hard to discover, or do we view it as an opportunity for 
>> users to complain to their admins that they need X feature in order to do 
>> what they need to do. Last time we talked about it, we were leaning towards 
>> the latter.
>> 
>> Maybe a happy middle ground is to have enough smarts in the system to show 
>> the templates, identify what parts won't work, gray out the template but 
>> provide a ui to "notifify the admin" of desire for X to work. That way users 
>> can easily feed back their desires.
>> 
>> Thanks,
>> Kevin
>> From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
>> Sent: Tuesday, July 14, 2015 11:34 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Heat] conditional resource exposure - second 
>> thoughts
>> 
>> Hi Heaters,
>> currently we already expose to the user only resources for services deployed 
>> in the cloud [1], and soon we will do the same based on whether actual user 
>> roles allow creating specific resources [2]. Here I would like to get your 
>> opinion on some of my thoughts regarding behavior of resource-type-list, 
>> resource-type-show and template-validate with this new features.
>> resource-type-list
>> We already (or soon will) hide unavailable in the cloud / for the user 
>> resources from the listing. But what if we add an API flag e.g. --all to 
>> show all registered in the engine resources? That would give any user a 
>> glimpse of what their Orchestration service can manage in principle, so they 
>> can nag the cloud operator to install additional OpenStack components or 
>> give them required roles :)
>> resource-type-show
>> Right now the plan is to disable "showing" unavailable to the user 
>> resources. But may be we should leave this as it is, for the same purpose as 
>> above (or again add a --all flag or such)?
>> template-validate
>> Right now Heat is failing validation for templates containing resource types 
>> not registered in the engine (e.g. typo). Should we also make this call 
>> available services- and r

Re: [openstack-dev] [magnum] Tom Cammann for core

[Tom Cammann]

Thanks team, happy to be here :)

Tom
> On 14 Jul 2015, at 23:02, Adrian Otto  wrote:
> 
> Tom,
> 
> It is my pleasure to welcome you to the magnum-core group. We are happy to 
> have you on the team.
> 
> Regards,
> 
> Adrian
> 
>> On Jul 9, 2015, at 7:20 PM, Adrian Otto  wrote:
>> 
>> Team,
>> 
>> Tom Cammann (tcammann) has become a valued Magnum contributor, and 
>> consistent reviewer helping us to shape the direction and quality of our new 
>> contributions. I nominate Tom to join the magnum-core team as our newest 
>> core reviewer. Please respond with a +1 vote if you agree. Alternatively, 
>> vote -1 to disagree, and include your rationale for consideration.
>> 
>> Thanks,
>> 
>> Adrian
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [cinder] Vedams' DotHill, Lenovo and HP MSA CIs are Unstable

[Mike Perez]

These three CIs are unstable and the drivers are in danger of being removed
from the Liberty release since the maintainer has not communicated any
maintenance happening.

http://paste.openstack.org/show/375584/
http://paste.openstack.org/show/375585/
http://paste.openstack.org/show/375586/

I will be requesting the HP MSA CI to be disabled in the third party list,
since it has failed the last 60 runs in the last 5 days.

This is unacceptable and we need Vedams to be more on top of this.

-- 
Mike Perez

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

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Fox, Kevin M]

Without a feedback loop of some kind, how does one solve issues like the 
following:

* Operator decides users don't need neutron NaaS because its "too complicated 
and users don't need it" (Seen on the mailing list multiple times)
* Software developer writes cloud templates that deploys software that needs 
private networks to work (For example, ElasticSearch)
* User wants to deploy said software but can't discover a working version.

User is sad because they can't find a working template to do what they want. 
They either reinvent the wheel, or give up and don't use the cloud for that 
task.

Being able to close the loop and let the operator easily know the users 
actually need something they aren't providing gives them the opportunity to fix 
the issue, benefiting all 3 parties.

Thanks,
Kevin


From: Randall Burt [randall.b...@rackspace.com]
Sent: Tuesday, July 14, 2015 2:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure 
- secondthoughts

Making users complain to admins that may have little to no control over what is 
and isn't available isn't a healthy strategy for user experience. Purposefully 
engineering hardship to try and influence operators to "do the right thing" in 
someone else's opinion sounds pretty counter productive to adoption as well.

FWIW, as a user, I don't want to see things I can't use because it just wastes 
my time. I agree that the docs are a good place to see "all the things" while 
querying the service should tell me what's available to me at the time.

On Jul 14, 2015, at 4:20 PM, "Fox, Kevin M" 
 wrote:

> We're kind of debating the same thing for the app catalog. Do we show 
> templates that don't work on a given cloud since they wont work, potentially 
> making useful tools hard to discover, or do we view it as an opportunity for 
> users to complain to their admins that they need X feature in order to do 
> what they need to do. Last time we talked about it, we were leaning towards 
> the latter.
>
> Maybe a happy middle ground is to have enough smarts in the system to show 
> the templates, identify what parts won't work, gray out the template but 
> provide a ui to "notifify the admin" of desire for X to work. That way users 
> can easily feed back their desires.
>
> Thanks,
> Kevin
> From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
> Sent: Tuesday, July 14, 2015 11:34 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Heat] conditional resource exposure - second 
> thoughts
>
> Hi Heaters,
> currently we already expose to the user only resources for services deployed 
> in the cloud [1], and soon we will do the same based on whether actual user 
> roles allow creating specific resources [2]. Here I would like to get your 
> opinion on some of my thoughts regarding behavior of resource-type-list, 
> resource-type-show and template-validate with this new features.
> resource-type-list
> We already (or soon will) hide unavailable in the cloud / for the user 
> resources from the listing. But what if we add an API flag e.g. --all to show 
> all registered in the engine resources? That would give any user a glimpse of 
> what their Orchestration service can manage in principle, so they can nag the 
> cloud operator to install additional OpenStack components or give them 
> required roles :)
> resource-type-show
> Right now the plan is to disable "showing" unavailable to the user resources. 
> But may be we should leave this as it is, for the same purpose as above (or 
> again add a --all flag or such)?
> template-validate
> Right now Heat is failing validation for templates containing resource types 
> not registered in the engine (e.g. typo). Should we also make this call 
> available services- and roles-sensitive? Or should we leave a way for a user 
> to check validity of any template with any in principle supported resources?
> The bottom line is we are good in making Heat service to be as much 
> self-documented via its own API as possible - let's keep doing that and make 
> any Heat deployment to be the Heat primer :)
> Eager to hear your opinions.
> [1] 
> http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html
> [2] 
> http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html
> Best regards,
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing Lis

Re: [openstack-dev] [Cinder] FFE Request: Re-add Quobyte Cinder Driver

[Mike Perez]

On 17:44 Jul 14, Silvan Kaiser wrote:
> Hello Cinder Community!
> I'd like to request a feature freeze exception for change [1], re-adding the 
> Quobyte driver to Cinder.
> 
> The driver was removed in change [2] due to missing CI activity [3], it was 
> originally added in the kilo release [4].
> We've been able to remove the CI's issues and it has been reporting for a 
> week now [5], stably testing and consistently showing two bugs (one in Nova 
> and one in our driver/Cinder),
> referenced on the CIs status page [6]. We're monitoring the CI results 
> continuously and the detected bugs are beeing addressed.
> The complete logs can be reviewed at [7].
> CI status changes are published on the Quobyte CI Status page in the wiki 
> [6], where there’s also our contact information.
> Thanks a lot for considering and best regards
> Silvan Kaiser
> (kaisers/casusbelli in IRC)
> 
> 
> [1] https://review.openstack.org/#/c/201507/
> [2] https://review.openstack.org/#/c/191192/
> [3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068609.html
> [4] https://review.openstack.org/#/c/94186/
> [5] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069183.html
> [6] https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI
> [7] http://176.9.127.22:8081/?C=M;O=D

The last 120 jobs have failed. Here's a paste of the 60 of them:

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

-- 
Mike Perez

__
OpenStack Development Mailing List (not 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] [magnum] Tom Cammann for core

[Adrian Otto]

Tom,

It is my pleasure to welcome you to the magnum-core group. We are happy to have 
you on the team.

Regards,

Adrian

> On Jul 9, 2015, at 7:20 PM, Adrian Otto  wrote:
> 
> Team,
> 
> Tom Cammann (tcammann) has become a valued Magnum contributor, and consistent 
> reviewer helping us to shape the direction and quality of our new 
> contributions. I nominate Tom to join the magnum-core team as our newest core 
> reviewer. Please respond with a +1 vote if you agree. Alternatively, vote -1 
> to disagree, and include your rationale for consideration.
> 
> Thanks,
> 
> Adrian


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

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Randall Burt]

Making users complain to admins that may have little to no control over what is 
and isn't available isn't a healthy strategy for user experience. Purposefully 
engineering hardship to try and influence operators to "do the right thing" in 
someone else's opinion sounds pretty counter productive to adoption as well.

FWIW, as a user, I don't want to see things I can't use because it just wastes 
my time. I agree that the docs are a good place to see "all the things" while 
querying the service should tell me what's available to me at the time.

On Jul 14, 2015, at 4:20 PM, "Fox, Kevin M" 
 wrote:

> We're kind of debating the same thing for the app catalog. Do we show 
> templates that don't work on a given cloud since they wont work, potentially 
> making useful tools hard to discover, or do we view it as an opportunity for 
> users to complain to their admins that they need X feature in order to do 
> what they need to do. Last time we talked about it, we were leaning towards 
> the latter.
> 
> Maybe a happy middle ground is to have enough smarts in the system to show 
> the templates, identify what parts won't work, gray out the template but 
> provide a ui to "notifify the admin" of desire for X to work. That way users 
> can easily feed back their desires.
> 
> Thanks,
> Kevin
> From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
> Sent: Tuesday, July 14, 2015 11:34 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Heat] conditional resource exposure - second 
> thoughts
> 
> Hi Heaters,
> currently we already expose to the user only resources for services deployed 
> in the cloud [1], and soon we will do the same based on whether actual user 
> roles allow creating specific resources [2]. Here I would like to get your 
> opinion on some of my thoughts regarding behavior of resource-type-list, 
> resource-type-show and template-validate with this new features.
> resource-type-list
> We already (or soon will) hide unavailable in the cloud / for the user 
> resources from the listing. But what if we add an API flag e.g. --all to show 
> all registered in the engine resources? That would give any user a glimpse of 
> what their Orchestration service can manage in principle, so they can nag the 
> cloud operator to install additional OpenStack components or give them 
> required roles :)
> resource-type-show
> Right now the plan is to disable "showing" unavailable to the user resources. 
> But may be we should leave this as it is, for the same purpose as above (or 
> again add a --all flag or such)?
> template-validate
> Right now Heat is failing validation for templates containing resource types 
> not registered in the engine (e.g. typo). Should we also make this call 
> available services- and roles-sensitive? Or should we leave a way for a user 
> to check validity of any template with any in principle supported resources?
> The bottom line is we are good in making Heat service to be as much 
> self-documented via its own API as possible - let's keep doing that and make 
> any Heat deployment to be the Heat primer :)
> Eager to hear your opinions.
> [1] 
> http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html
> [2] 
> http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html
> Best regards,
> -- 
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

[Fox, Kevin M]

We're kind of debating the same thing for the app catalog. Do we show templates 
that don't work on a given cloud since they wont work, potentially making 
useful tools hard to discover, or do we view it as an opportunity for users to 
complain to their admins that they need X feature in order to do what they need 
to do. Last time we talked about it, we were leaning towards the latter.

Maybe a happy middle ground is to have enough smarts in the system to show the 
templates, identify what parts won't work, gray out the template but provide a 
ui to "notifify the admin" of desire for X to work. That way users can easily 
feed back their desires.

Thanks,
Kevin

From: Pavlo Shchelokovskyy [pshchelokovs...@mirantis.com]
Sent: Tuesday, July 14, 2015 11:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Heat] conditional resource exposure - second thoughts


Hi Heaters,

currently we already expose to the user only resources for services deployed in 
the cloud [1], and soon we will do the same based on whether actual user roles 
allow creating specific resources [2]. Here I would like to get your opinion on 
some of my thoughts regarding behavior of resource-type-list, 
resource-type-show and template-validate with this new features.

resource-type-list
We already (or soon will) hide unavailable in the cloud / for the user 
resources from the listing. But what if we add an API flag e.g. --all to show 
all registered in the engine resources? That would give any user a glimpse of 
what their Orchestration service can manage in principle, so they can nag the 
cloud operator to install additional OpenStack components or give them required 
roles :)

resource-type-show
Right now the plan is to disable "showing" unavailable to the user resources. 
But may be we should leave this as it is, for the same purpose as above (or 
again add a --all flag or such)?

template-validate
Right now Heat is failing validation for templates containing resource types 
not registered in the engine (e.g. typo). Should we also make this call 
available services- and roles-sensitive? Or should we leave a way for a user to 
check validity of any template with any in principle supported resources?

The bottom line is we are good in making Heat service to be as much 
self-documented via its own API as possible - let's keep doing that and make 
any Heat deployment to be the Heat primer :)

Eager to hear your opinions.

[1] 
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html

[2] 
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html

Best regards,

--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Juno Compute RPC v3.33 Endpoint Error when the Controller is running rabbitMQ v3.4.2

[Gregg Marxer]

3rd posting

Hi Experts,

I have a three node Juno system running on Ubuntu 14.04. On the compute node I 
keep getting the following Endpoint does not support RPC version 3.33 to caller 
error when I launch a Nova instance. The Controller is running rabbitMQ v3.4.2. 
So I do not understand why the compute node thinks the endpoint does not 
support v3.33. I tried both rabbitMQ v3.3.3 and v3.5 on the compute node with 
the same result. Data below. Any suggestions?

https://ask.openstack.org/en/question/69203/juno-controller-rabbitmq-v342-but-compute-node-v333-rpc-error/

Regards,

Gregg Marxer | Field Systems Engineer
O 949.631.6733   M 732.713.1361
f5.com | synthesis.f5.com

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

Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron

[Matt Riedemann]

On 7/14/2015 3:43 PM, Cale Rath wrote:

Hi,

I created a patch to fail on the proxy call to Neutron for used limits,
found here: https://review.openstack.org/#/c/199604/

This patch was done because of this:
http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies,
where it’s stated that Nova shouldn’t be proxying API calls.

That said, Matt Riedemann brings up the point that this breaks the case
where Neutron is installed and we want to be more graceful, rather than
just raising an exception.  Here are some options:

1. fail - (the code in the patch above)
2. proxy to neutron for floating ips and security groups - that's what
the original change was doing back in havana
3. return -1 or something for floatingips/security groups to indicate
that we don't know, you have to get those from neutron

Does anybody have an opinion on which option we should do regarding API
proxies in this case?

Thanks,

Cale Rath


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



I prefer the proxy option, despite that we don't want to do more proxies 
to other services, it's the least of all evils here in my opinion.


I don't think we can do #1, that breaks anyone using those APIs and is 
using Neutron, so it's a non-starter.


#3 is an API change in semantics which would at least be a microversion 
and is kind of clunky.


For #2 we at least have the nova.network.base_api which we didn't have 
in Havana when I was originally working on this, that would abstract the 
neutron-specific cruft out of the nova-api code.  The calls to neutron 
were pretty simple from what I remember - we could just resurrect the 
old patch:


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

Another option is #4, we mark the bug as won't fix and we log a warning 
if neutron is configured saying some of the resources aren't going to be 
correct, use the neutron API to get information for quotas on security 
groups, floating IPs, etc.  That's also kind of gross IMO, but it's an 
option.


--

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] [Keystone] Symbol not found: _BIO_new_CMS

[Dolph Mathews]

Also for the sake of future googlers: we gave up on supporting keystone
development in OS X a release or two ago due to the increasing number of
workarounds like this that we had to track (a few of which impacted the
code base itself, and were thus dropped).

On Tue, Jul 14, 2015 at 3:42 PM, Kirill Zaitsev 
wrote:

> Just for the sake of future googlers. I’ve encountered the same problem
> (with horizon actually) and managed to solve it.
>
> 1) install and link latest openssl from homebrew: brew update && brew
> install openssl && brew link --force openssl
> 2) run tox, it fails.
> 3) manually activate the environment you want: . .tox/venv/bin/activate
> 4) build cryptography package with brew
> ssl: LDFLAGS=-L/usr/local/opt/openssl/lib
> CPPFLAGS=-I/usr/local/opt/openssl/include pip install --force-reinstall
> --upgrade --no-binary cryptography cryptography
> 5) deactivate
>
> that’s it — that should do the trick. Someone might be able to suggest a
> better way to do this, but this variant works for me. (As long as I do not
> rebuild venv too often =))
>
> --
> Kirill Zaitsev
> Murano team
> Software Engineer
> Mirantis, Inc
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not 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] Reminder: July 16 is non-priority feature proposal freeze

[John Garbutt]

On 14 July 2015 at 18:40, Ed Leafe  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 07/14/2015 05:52 AM, John Garbutt wrote:
>
>> Please note, the non-priority feature freeze is on: July 30

So technically both are correct, neither are complete, oops:
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule

July 16: non-priority feature proposal freeze
July 30: liberty-2 -- non-priority feature freeze

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] [Horizon] Liberty Mid Cycle Meetup

[Tripp, Travis S]

Hello everybody,

Just a reminder about the mid-cycle next week.  If you haven’t already, please 
add your name to the list[0] of people coming so we have a final head count on 
ordering morning / afternoon snacks. If your name is on the list and you aren’t 
coming, please remove it or indicate that you’d try to attend remotely. We’ll 
try to have webex or something via a laptop, which hopefully will be better 
than nothing.

The mid-cycle is intended to be a lot of pairing up sessions on priorities 
established at the summit [2]. However, if you have specific topics to discuss, 
just add them somewhere on the agenda list[0] so they are tracked and we can 
cover them. The times for sessions on the agenda likely won’t be followed too 
closely as small group break outs happen.

For Tuesday evening, if anybody is interested we might do a short hike in the 
nearby foothills before dinner. If so, bring some comfortable walking shoes.

And a reminder that location info is at link [2] below.


[0] Agenda / Attendance List: 
https://docs.google.com/spreadsheets/d/1w0eI6SPCA2IrOyHiEYC2uDO3fbYGzahZRUQSva0UD3Y/edit#gid=1788841692

[1] Liberty Priorities:
https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities

[2] Info on location is here:
https://etherpad.openstack.org/p/horizon-liberty-midcycle


Thanks,
Travis




On 6/19/15, 10:14 AM, "Tripp, Travis S"  wrote:

>Hi everybody,
>
>I got confirmation for hosting the mid cycle meetup at the HP Office in Fort 
>Collins on July 21st - 23rd.  I’ve put details on the location with a couple 
>nearby hotels on the following ether pad.  The room we have reserved can hold 
>about 40 people, but I’ve requested for it to be setup so that we can have a 
>couple different work areas in the room. There will be a u-shape configuration 
>at the front of the room for 20 and another u-shape at the back of the room 
>for 10 to be used for breakout discussions.
>
>https://etherpad.openstack.org/p/horizon-liberty-midcycle
>
>A question I have is whether we’ll want to have lunch catered or if we’ll want 
>to let everybody out for an hour to get lunch from one of the nearby 
>restaurants.  There is a cafeteria on site as well.  If we decide to have it 
>catered, I’ll have to know of any special dietary requests.
>
>Thanks,
>Travis
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack][nova]

[Cale Rath]

Hi,

I created a patch to fail on the proxy call to Neutron for used limits, found 
here: https://review.openstack.org/#/c/199604/

This patch was done because of this: 
http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies
 
,
 where it’s stated that Nova shouldn’t be proxying API calls.

That said, Matt Riedemann brings up the point that this breaks the case where 
Neutron is installed and we want to be more graceful, rather than just raising 
an exception.  Here are some options:

1. fail - (the code in the patch above)
2. proxy to neutron for floating ips and security groups - that's what the 
original change was doing back in havana
3. return -1 or something for floatingips/security groups to indicate that we 
don't know, you have to get those from neutron

Does anybody have an opinion on which option we should do regarding API proxies 
in this case?

Thanks,

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

Re: [openstack-dev] [Keystone] Symbol not found: _BIO_new_CMS

[Kirill Zaitsev]

Just for the sake of future googlers. I’ve encountered the same problem (with 
horizon actually) and managed to solve it.

1) install and link latest openssl from homebrew: brew update && brew install 
openssl && brew link --force openssl
2) run tox, it fails.
3) manually activate the environment you want: . .tox/venv/bin/activate
4) build cryptography package with brew ssl: 
LDFLAGS=-L/usr/local/opt/openssl/lib CPPFLAGS=-I/usr/local/opt/openssl/include 
pip install --force-reinstall --upgrade --no-binary cryptography cryptography
5) deactivate

that’s it — that should do the trick. Someone might be able to suggest a better 
way to do this, but this variant works for me. (As long as I do not rebuild 
venv too often =))

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

Re: [openstack-dev] [Cinder] python-cinderclient functional tests

[Ivan Kolodyazhny]

I've added this topic to the meeting agenda [1]

[1] https://wiki.openstack.org/wiki/CinderMeetings#Next_meeting

Regards,
Ivan Kolodyazhny

On Mon, Jul 13, 2015 at 10:23 PM, Matthew Treinish 
wrote:

> On Mon, Jul 13, 2015 at 12:04:05PM -0700, Mike Perez wrote:
> > On 16:28 Jul 10, Ivan Kolodyazhny wrote:
> > > Hi Mike,
> > >
> > > Unfortunately, we don't get a lot of stats [1] because we don't run it
> > > often. I've added 'check experimental' comment to latest
> > > python-cinderclient review request to get more stats.
> > >
> > > Review request to make this voting:
> https://review.openstack.org/#/c/200522/
> > >
> > > [1]
> > >
> http://graphite.openstack.org/render/?width=877&height=548&_salt=1436533755.887&from=00%3A00_20150524&until=23%3A59_20150710&target=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.FAILURE&target=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.SUCCESS&target=stats.zuul.pipeline.experimental.openstack.python-cinderclient.total_changes&title=check-cinderclient-dsvm-functional
> >
> > Add an agenda item to the next Cinder meeting. Sure there should be no
> > objections.
> >
>
> Just an FYI that these tests used to always be voting until they were
> removed
> from tempest. [1][2] Almost every other project that did the same client
> test
> migration from tempest just made the new client specific jobs voting from
> the
> start so there was no loss in coverage. I'm not entirely sure why
> cinderclient
> got stuck as experimental jobs, but it doesn't seem overly contentious to
> me
> to just flip the switch.
>
> -Matt Treinish
>
> [1] https://review.openstack.org/#/c/178757/
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-April/063018.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-dev] [qa] identity v3 issue causing non-admin job to fail

[David Kranz]

Now that the tempest periodic jobs are back (thanks infra!), I was 
looking into the real failures. It seems the main one is caused by the 
fact that the v3 check for primary creds fails if 'admin_domain_name' in 
the identity section is None, which it is when devstack configures 
tempest for non-admin.


The problem is with this code and there is even a comment related to 
this issue. There are various ways to fix this but I'm not sure what the 
value should be for the non-admin case. Andrea, any ideas?


 -David

def get_credentials(fill_in=True, identity_version=None, **kwargs):
params = dict(DEFAULT_PARAMS, **kwargs)
identity_version = identity_version or CONF.identity.auth_version
# In case of "v3" add the domain from config if not specified
if identity_version == 'v3':
domain_fields = set(x for x in 
auth.KeystoneV3Credentials.ATTRIBUTES

if 'domain' in x)
if not domain_fields.intersection(kwargs.keys()):
# TODO(andreaf) It might be better here to use a dedicated 
config

# option such as CONF.auth.tenant_isolation_domain_name
params['user_domain_name'] = CONF.identity.admin_domain_name
auth_url = CONF.identity.uri_v3
else:
auth_url = CONF.identity.uri
return auth.get_credentials(auth_url,
fill_in=fill_in,
identity_version=identity_version,
**params)


__
OpenStack Development Mailing List (not 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] [Openstack] Rescinding the M name decision

[David Medberry]

Thanks Lauren. Mi taco es su taco.

On Tue, Jul 14, 2015 at 12:53 PM, Lauren Sell  wrote:

> Good news. After finalizing the trademark checks and giving the community
> time to weigh in, Mitaka will be the name of the M release.
>
> Thanks again for the great discussion around this topic, and for the
> willingness to be responsive to the concerns of fellow community members.
>
>
> > On Jul 9, 2015, at 2:18 PM, Tim Bell  wrote:
> >
> > Feel free to give input on the Mitaka proposal.
> >
> > Tim
> >
> >> -Original Message-
> >> From: Jonathan Bryce [mailto:jbr...@jbryce.com]
> >> Sent: 09 July 2015 20:52
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decision
> >>
> >>> On Jul 9, 2015, at 9:35 AM, Russell Bryant  wrote:
> >>>
> >>> On 07/09/2015 09:19 AM, Neil Jerram wrote:
>  In the hope of forestalling an unnecessary sub-thread...
> 
>  Mita was #1 in the vote, so has presumably already been ruled out by
>  OpenStack's legal review.
> >>>
> >>> That is correct.
> >>
> >>
> >> Hi everyone,
> >>
> >> I’ve really loved seeing everyone’s understanding and engagement on this
> >> thread as we worked through the release cycle naming for ‘M’. This was
> the
> >> first attempt to follow a new process, so not surprisingly, we found
> some
> >> improvements in the algorithm for the future. Still it’s awesome to see
> how
> >> constructive and positive the whole conversation has been.
> >>
> >> I wanted to provide a quick update on the status of the Foundation’s
> >> reviews of the names. First, as Russell mentioned above, after the
> voting
> >> was completed, we asked our trademark counsel to do checks on the top 3
> >> names. The first two both had significant trademark issues with existing
> >> trademark holders in the same space that would have prevented us from
> >> using the names in most jurisdictions where we have our largest
> >> communities (US, Europe and Asia). The 3rd choice was relatively low
> risk
> >> and so we passed word back to Monty who announced it. Once we realized
> >> there were other issues with Meiji, we asked for an expedited check of
> the
> >> next 3 names: Mitaka, Musashi, and Meguro. The preliminary check shows
> >> that Mitaka and Meguro both present an acceptable level of risk, while
> >> Musashi is higher on the risk scale and would probably create problems
> for
> >> usage.
> >>
> >> At this time, we’re going to do a deeper check on Mitaka, which was the
> #4
> >> candidate in voting and would be next in line after Meiji. I know
> Itoh-san
> >> mentioned the Mitaka locale has the potential to be associated with
> certain
> >> corporations in Japan, but my personal feeling is that may not be
> significant
> >> enough to override it’s position in the voting and it’s availability
> for use.
> >>
> >> I’d encourage anyone with other concerns about Mitaka to post those
> >> within the next 24 hours so we can appropriately consider and discuss
> >> them. We should have results on the deeper trademark check by next week
> >> as well and can hopefully settle on a final name.
> >>
> >> Thanks again for all the discussion and participation and especially to
> >> Monty who’s been on the front lines of helping us navigate this. Feel
> free to
> >> let me know if you have any other questions,
> >>
> >> Jonathan
> >> 210-317-2438
> >>
> >>
> >> __
> >> 
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-
> >> requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

[Zane Bitter]

On 14/07/15 14:34, Pavlo Shchelokovskyy wrote:

Hi Heaters,

currently we already expose to the user only resources for services
deployed in the cloud [1], and soon we will do the same based on whether
actual user roles allow creating specific resources [2]. Here I would
like to get your opinion on some of my thoughts regarding behavior of
resource-type-list, resource-type-show and template-validate with this
new features.

resource-type-list
We already (or soon will) hide unavailable in the cloud / for the user
resources from the listing. But what if we add an API flag e.g. --all to
show all registered in the engine resources? That would give any user a
glimpse of what their Orchestration service can manage in principle, so
they can nag the cloud operator to install additional OpenStack
components or give them required roles :)


I worry that this could result in leakage of potentially-sensitive 
information. e.g. once we have this feature implemented, an operator 
could deploy a plugin that is only for the use of one particular user, 
who has a custom role. I don't think it would be expected that other 
users (without that role) in other tenants could find out about that, 
even if all they can find out is the name of the resource type.


I definitely think that admins should have a way of getting a list of 
_all_ resource types (preferably annotated with the roles required to 
use them). Just not ordinary users.



resource-type-show
Right now the plan is to disable "showing" unavailable to the user
resources. But may be we should leave this as it is, for the same
purpose as above (or again add a --all flag or such)?


This is totally unnecessary IMHO for the reasons Clint mentioned. Again, 
I could imagine an exception for admins though, since I suspect that 
this API is the only way we can annotate resource types with the roles 
required without performing major surgery on resource-type-list.



template-validate
Right now Heat is failing validation for templates containing resource
types not registered in the engine (e.g. typo). Should we also make this
call available services- and roles-sensitive? Or should we leave a way
for a user to check validity of any template with any in principle
supported resources?


You call template-validate when you're about to launch the template and 
you want to know what parameters and stuff are required. If YOU cannot 
launch THIS template on THIS cloud right NOW it should fail, period.


cheers,
Zane.


The bottom line is we are good in making Heat service to be as much
self-documented via its own API as possible - let's keep doing that and
make any Heat deployment to be the Heat primer :)

Eager to hear your opinions.

[1]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html

[2]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html

Best regards,

--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com


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




__
OpenStack Development Mailing List (not 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] [openstack-announce] End of life for managed stable/icehouse branches

[Thomas Goirand]

On 07/14/2015 10:29 AM, Ihar Hrachyshka wrote:
> On 07/14/2015 12:33 AM, Thomas Goirand wrote:
>> I missed this announce...
> 
>> On 07/02/2015 05:32 AM, Jeremy Stanley wrote:
>>> Per the Icehouse EOL discussion[1] last month, now that the
>>> final 2014.1.5 release[2] is behind us I have followed our usual
>>> end of life steps for stable/icehouse branches on repos under the
>>> control of the OpenStack Release Cycle Management project-team. 
>>> Specifically, for any repos with the release:managed[3] tag, 
>>> icehouse-specific test jobs were removed from our CI system and
>>> all open change reviews were abandoned for stable/icehouse. Then
>>> the final states of the branches were tagged as "icehouse-eol"
>>> and the branches subsequently deleted.
> 
>> I believe I asked you about 10 times to keep these branches alive,
>> so that distributions could work together on a longer support, even
>> without a CI behind it.
> 
>> I have also asked for a private gerrit for maintaining the
>> Icehouse patches after EOL.
> 
>> While I understand the later means some significant work, I don't 
>> understand why you have deleted the Icehouse branches.
> 
>> Effectively, under these conditions, I am giving up doing any kind
>> of coordination between distros for security patches of Icehouse.
>> :(
> 
> As far as I know, there was no real coordination on those patches
> before, neither I saw any real steps from any side to get it up.

Well... as far as I know, you were not there during the conversations we
had at the summits about this. Neither you are on my list of Icehouse
security persons. So I fail to see how you could be in the loop for this
indeed.

> That said, anyone can come up with an initiative to maintain those
> branches under some 3party roof (just push -eol tag into github and
> advertise), and if there is real (and not just anticipated)
> collaboration going on around it, then the project may reconsider
> getting it back in the big stadium.

I have a list of contacts for each and every downstream distributions.
All of them agreed to work under this coordinated Git repo, so that we
share the same patch. The only issue is that during embargo period, we
can't discuss this type of patches in public. Which is why a private
gerrit was the way to go. Though for not-embargoed stuff, we could well
have used the already existing Gerrit infrastructure, without a CI (as
all distro are running their own tests anyway).

> I am tired to say that again and again, but there should be some
> resource investment from interested parties, upfront, before infra
> takes part of the burden on their shoulders. Asking won't help.

How do you expect to see anything happening before Icehouse effectively
gets EOL? By the way, I haven't asked anything but *not* doing
something. I don't see how much "burden" I'm putting on infra here.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing List (not 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][tests] Fix it friday! [mock failure in CI]

[Robert Collins]

On 14 July 2015 at 22:41, Kevin Benton  wrote:
> Oh, no I didn't. By the time I got around to it I saw 264 and figured that
> would cover the issue.

Ok - could you check? 1.1.3 has issue 264 fixed, and I'd like to fix
this one too, if its still an issue. Bonus points for checking against
3.5's unittest,mock too.

-Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [all][tests] Fix it friday! [mock failure in CI]

[Robert Collins]

On 13 July 2015 at 13:04, Dave McCowan (dmccowan)  wrote:
> Has anyone else seen this error with the new mock?
>
> 'self' parameter lacking default value
>
>
> My function under test runs correctly, but then Mock throws this TypeError
> when comparing the parameters in assert_calls_with().
>
> I'm seeing this in Barbican.  More info below [1][2].
>
> --Dave
>
> [1] Complete backtrace
> ==
> FAIL:
> barbican.tests.plugin.test_kmip.WhenTestingKMIPSecretStore.test_store_passp
> hrase_secret_assert_called
> --
> _StringException: Traceback (most recent call last):
>   File "/Users/dmccowan/barbican/barbican/tests/plugin/test_kmip.py", line
> 432, in test_store_passphrase_secret_assert_called
> credential=self.credential)
>   File
> "/Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/mock/m
> ock.py", line 941, in assert_called_once_with
> return self.assert_called_with(*args, **kwargs)
>   File
> "/Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/mock/m
> ock.py", line 930, in assert_called_with
> six.raise_from(AssertionError(_error_message(cause)), cause)
>   File
> "/Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/six.py
> ", line 692, in raise_from
> raise value
> AssertionError: Expected call: mock(credential=Struct(),
> object_type=, secret=,
> template_attribute=)
> Actual call: mock(credential=Struct(),
> object_type=, secret=Struct(),
> template_attribute=Struct())
> 'self' parameter lacking default value

Please see if this is a problem in python 3.5's unittest.mock. If it
is: file it in the Python bug tracker (and +nosy me there
[rbcollins]). If its not a problem in python 3.5's unittest.mock, then
file it in the mock bug tracker, and I'll figure out why its behaving
differently.

Cheers,
Rob



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

[Thomas Goirand]

On 07/14/2015 03:55 AM, Jeremy Stanley wrote:
> On 2015-07-14 00:33:52 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> I believe I asked you about 10 times to keep these branches alive, so
>> that distributions could work together on a longer support, even without
>> a CI behind it.
> 
> And the project consensus has seemed to disagree with this after
> careful discussion, each time it's brought up. Distributions
> collaborating upstream on stable branch support would entail helping
> keep those branches tested upstream. As a project we've consistently
> stated that publishing updates to stable branches without sufficient
> testing is an affront to our quality assurance stance. The final
> state of the upstream stable/icehouse branch, as with each previous
> stable branch all the way back to stable/diablo, is tagged in the
> repository so that you can construct your own continuation of
> stable/icehouse from the same point as needed.
> 
>> I have also asked for a private gerrit for maintaining the Icehouse
>> patches after EOL.
> [...]
> 
> I do apologize for not setting up a separate private Gerrit instance
> for embargoed security fix code reviewing. It would be a help to me
> and the rest of the VMT to have it, I simply haven't had the
> available time I'd hoped to be able to work out remaining
> implementation details for deploying and maintaining it. That said,
> its priority has decreased as the VMT is trying to get a little more
> cautious about only embargoing vulnerability reports that actually
> benefit enough from a brief advance notice to downstream
> stakeholders to offset the significant cost in efficiency of the
> embargo process (only a small amount of which is due to the tools we
> end up using for private code review).
> 
> However, as I explained to you at the Liberty Design Summit after
> discussion with members of the infrastructure team, we're also not
> comfortable maintaining stable branches of projects in a private
> Gerrit instance any longer than we do in the normal public one, and
> would want to remove inactive branches from it at the same time
> their public counterparts reach end of life.
> 
> Since I feel like I'm starting to repeat myself at this point, I'll
> leave it to others to continue the thread this time. If you're
> interested in overhauling the stable branch EOL process (I didn't
> design and plan it, I merely pull the levers and push the buttons),
> that discussion should involve the stable branch release managers
> and the rest of the release team along with the quality assurance
> team.

Jeremy,

I'm very disappointed, because this isn't at all what I've been told
during each and every summit since the release of Icehouse.

The conversations we had during all summits were all about you (and
others) saying that it was really ok to not destroy the branches. Never
you raised your concern about any issue, and I was counting on this to
organize security support for Icehouse for embargoed issues.

While I do understand that you didn't have time for this private gerrit,
I don't get why it's not ok to just leave the branch open, without the
CI (you could rename the branch if you didn't want to show any blessing
from the project).

Now, since the upstream OpenStack doesn't offer any help for Icehouse
which absolutely *all* downstream distributions offer LTS support, we're
back to what I feared from the start: chaos and no serious coordination
possible between distros, unless we do absolutely everything by
ourselves (including the infrastructure to host a gerrit and share
patches). I will *not* have the time to do this.

I just hope individual project members will help doing some of the
backport work.

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

[Ryan Brown]

On 07/14/2015 02:46 PM, Clint Byrum wrote:
> Excerpts from Pavlo Shchelokovskyy's message of 2015-07-14 11:34:37 -0700:
>> Hi Heaters,
>>
>> currently we already expose to the user only resources for services
>> deployed in the cloud [1], and soon we will do the same based on whether
>> actual user roles allow creating specific resources [2]. Here I would like
>> to get your opinion on some of my thoughts regarding behavior of
>> resource-type-list, resource-type-show and template-validate with this new
>> features.
>>
>> resource-type-list
>> We already (or soon will) hide unavailable in the cloud / for the user
>> resources from the listing. But what if we add an API flag e.g. --all to
>> show all registered in the engine resources? That would give any user a
>> glimpse of what their Orchestration service can manage in principle, so
>> they can nag the cloud operator to install additional OpenStack components
>> or give them required roles :)
>>
> 
> There are more variables that lead to a resource being hidden than
> the catalog. The version of Heat, whether the plugin is available,
> libraries installed on the server, etc. The canonical place for all
> things possible, and the place that users should be encouraged to use,
> is the documentation of Heat. These API's should only be for inspection
> of what is available on the Heat service one is talking to.

I'd agree with Clint.

Think about a user that says to themselves "Hey, I want to see *all* the
Heat resources!" Will they:

1) Google "heat resources openstack" or similar, landing at our docs
page with the list in a nice, human-friendly format.
2) Look in the API endpoint docs and find a flag to show disabled
resources. Then call that endpoint and read the JSON response.

I think the answer is going to be (1) for the vast majority of users

>> template-validate
>> Right now Heat is failing validation for templates containing resource
>> types not registered in the engine (e.g. typo). Should we also make this
>> call available services- and roles-sensitive? Or should we leave a way for
>> a user to check validity of any template with any in principle supported
>> resources?
>>
> 
> I believe the current behavior is correct. The idea is to be able to
> edit a template, and then validate it on all the clouds you want to push
> it to.

Maybe it would be valuable to distinguish (when failing a validation)
between "Resource Foo::Bar is not a thing at all" and "Resource
OS::Zaqar::Queue is disabled on this cloud".

I'm not sure if validate currently makes that distinction, but it likely
should.

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

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

Re: [openstack-dev] OpenStack Mitaka (三鷹) - Our next release name has been selected

[Ian Cordasco]

On 7/14/15, 13:47, "Monty Taylor"  wrote:

>Hi everybody!
>
>Ok. There is nothing more actually useful I can say that isn't in the
>subject line. As I mentioned previously, the preliminary results from
>our name election are here:
>
>http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc
>
>As you are all probably aware by now, as a follow on step, the OpenStack
>Foundation staff assessed the names chosen for legal risk in the order
>we ranked them. The first two had significant identified problems so we
>skipped them. The third had no legal problems, but after announcing it
>as the choice, it came to light that there were significant social
>issues surrounding the name.
>
>The fourth on the list, Mitaka (三鷹) is clear.
>
>So please join me in welcoming the latest name to our family ... and if
>you, like me, are not a native Japanese speaker, in learning two (more)
>new characters.
>
>I'd also like to thank everyone in our community for understanding. As
>we try our best to be an inclusive worldwide community, the
>opportunities for unwitting missteps are vast and ultimately probably
>unavoidable. Being able to recognize and deal with them and learn from
>them as they occur makes me proud of who we are and what we've become.

I agree. It's really encouraging to see a community as large as OpenStack
embrace inclusivity and empathy around social issues.

__
OpenStack Development Mailing List (not 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] [Openstack] Rescinding the M name decision

[Lauren Sell]

Good news. After finalizing the trademark checks and giving the community time 
to weigh in, Mitaka will be the name of the M release. 

Thanks again for the great discussion around this topic, and for the 
willingness to be responsive to the concerns of fellow community members.


> On Jul 9, 2015, at 2:18 PM, Tim Bell  wrote:
> 
> Feel free to give input on the Mitaka proposal.
> 
> Tim
> 
>> -Original Message-
>> From: Jonathan Bryce [mailto:jbr...@jbryce.com]
>> Sent: 09 July 2015 20:52
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Openstack] Rescinding the M name decision
>> 
>>> On Jul 9, 2015, at 9:35 AM, Russell Bryant  wrote:
>>> 
>>> On 07/09/2015 09:19 AM, Neil Jerram wrote:
 In the hope of forestalling an unnecessary sub-thread...
 
 Mita was #1 in the vote, so has presumably already been ruled out by
 OpenStack's legal review.
>>> 
>>> That is correct.
>> 
>> 
>> Hi everyone,
>> 
>> I’ve really loved seeing everyone’s understanding and engagement on this
>> thread as we worked through the release cycle naming for ‘M’. This was the
>> first attempt to follow a new process, so not surprisingly, we found some
>> improvements in the algorithm for the future. Still it’s awesome to see how
>> constructive and positive the whole conversation has been.
>> 
>> I wanted to provide a quick update on the status of the Foundation’s
>> reviews of the names. First, as Russell mentioned above, after the voting
>> was completed, we asked our trademark counsel to do checks on the top 3
>> names. The first two both had significant trademark issues with existing
>> trademark holders in the same space that would have prevented us from
>> using the names in most jurisdictions where we have our largest
>> communities (US, Europe and Asia). The 3rd choice was relatively low risk
>> and so we passed word back to Monty who announced it. Once we realized
>> there were other issues with Meiji, we asked for an expedited check of the
>> next 3 names: Mitaka, Musashi, and Meguro. The preliminary check shows
>> that Mitaka and Meguro both present an acceptable level of risk, while
>> Musashi is higher on the risk scale and would probably create problems for
>> usage.
>> 
>> At this time, we’re going to do a deeper check on Mitaka, which was the #4
>> candidate in voting and would be next in line after Meiji. I know Itoh-san
>> mentioned the Mitaka locale has the potential to be associated with certain
>> corporations in Japan, but my personal feeling is that may not be significant
>> enough to override it’s position in the voting and it’s availability for use.
>> 
>> I’d encourage anyone with other concerns about Mitaka to post those
>> within the next 24 hours so we can appropriately consider and discuss
>> them. We should have results on the deeper trademark check by next week
>> as well and can hopefully settle on a final name.
>> 
>> Thanks again for all the discussion and participation and especially to
>> Monty who’s been on the front lines of helping us navigate this. Feel free to
>> let me know if you have any other questions,
>> 
>> Jonathan
>> 210-317-2438
>> 
>> 
>> __
>> 
>> OpenStack Development Mailing List (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] OpenStack Mitaka (三鷹) - Our next release name has been selected

[Monty Taylor]

Hi everybody!

Ok. There is nothing more actually useful I can say that isn't in the
subject line. As I mentioned previously, the preliminary results from
our name election are here:

http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4983776e190c8dbc

As you are all probably aware by now, as a follow on step, the OpenStack
Foundation staff assessed the names chosen for legal risk in the order
we ranked them. The first two had significant identified problems so we
skipped them. The third had no legal problems, but after announcing it
as the choice, it came to light that there were significant social
issues surrounding the name.

The fourth on the list, Mitaka (三鷹) is clear.

So please join me in welcoming the latest name to our family ... and if
you, like me, are not a native Japanese speaker, in learning two (more)
new characters.

I'd also like to thank everyone in our community for understanding. As
we try our best to be an inclusive worldwide community, the
opportunities for unwitting missteps are vast and ultimately probably
unavoidable. Being able to recognize and deal with them and learn from
them as they occur makes me proud of who we are and what we've become.

Thanks!
Monty

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

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

[Clint Byrum]

Excerpts from Pavlo Shchelokovskyy's message of 2015-07-14 11:34:37 -0700:
> Hi Heaters,
> 
> currently we already expose to the user only resources for services
> deployed in the cloud [1], and soon we will do the same based on whether
> actual user roles allow creating specific resources [2]. Here I would like
> to get your opinion on some of my thoughts regarding behavior of
> resource-type-list, resource-type-show and template-validate with this new
> features.
> 
> resource-type-list
> We already (or soon will) hide unavailable in the cloud / for the user
> resources from the listing. But what if we add an API flag e.g. --all to
> show all registered in the engine resources? That would give any user a
> glimpse of what their Orchestration service can manage in principle, so
> they can nag the cloud operator to install additional OpenStack components
> or give them required roles :)
> 

There are more variables that lead to a resource being hidden than
the catalog. The version of Heat, whether the plugin is available,
libraries installed on the server, etc. The canonical place for all
things possible, and the place that users should be encouraged to use,
is the documentation of Heat. These API's should only be for inspection
of what is available on the Heat service one is talking to.

> 
> template-validate
> Right now Heat is failing validation for templates containing resource
> types not registered in the engine (e.g. typo). Should we also make this
> call available services- and roles-sensitive? Or should we leave a way for
> a user to check validity of any template with any in principle supported
> resources?
> 

I believe the current behavior is correct. The idea is to be able to
edit a template, and then validate it on all the clouds you want to push
it to.

__
OpenStack Development Mailing List (not 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] [magnum] The way magnum-conductor communicates with k8s master

[Steven Dake (stdake)]

From: Adrian Otto mailto:adrian.o...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 11:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates 
with k8s master


On Jul 13, 2015, at 8:40 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:



From: "OTSUKA, Motohiro" mailto:yuany...@oeilvert.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 13, 2015 at 8:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates 
with k8s master

Hi, Wanghua

  Currently magnum-conductor can communicates with k8s master which has a 
floating ip in all-in-one deployment. But if magnum-conductor is not deployed 
on the neutron network node which has the br-ex, how can magnum-conductor 
communicate with k8s master. The magnum-conductor node then has no access to 
the k8s master.
Currently this is a limitation of our architecture.


The floating IP is a public routed network, so it should be able to communicate 
in a properly setup cloud.

  Another question:
  Magnum-conductor only communicate with k8s master, why k8s minion has a 
floating ip too? What is the floating ip of k8s minion used for?

I think, there is no reason.
Historically, Our heat template come from larsks/heat-kubernetes [1] template.
larsks/heat-kubernetes provides floating ip to minion nodes, this is just a 
reason.

The minion floating ips are needed to access the micro-service front ends from 
the internet.

To be clear, the actual requirement is that the minion nodes must be able to 
make TCP connections to the master node. Depending on the routing setup on your 
nodes, and the arrangement of your network, that could be possible without a 
floating ip on the minion nodes. With that in mind, having a publicly routable 
address (floating ip) on your minion node is one way to produce such 
connectivity.

I’m sure we would be open to a proposal that eliminates our requirement for the 
floating ip on the minion nodes that would work properly in various network 
environments.

The minions need to be publically routed, but the master does not.  The reason 
minions need to be publically routed is because front end applications (such as 
chrome) access the microservices running in the k8s cluster via their 
publically routed ip address.

Regards
-steve


Adrian


Regards
-steve



[1]: https://github.com/larsks/heat-kubernetes

Thanks
-Yuanying

__
OpenStack Development Mailing List (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] [Heat] conditional resource exposure - second thoughts

[Pavlo Shchelokovskyy]

Hi Heaters,

currently we already expose to the user only resources for services
deployed in the cloud [1], and soon we will do the same based on whether
actual user roles allow creating specific resources [2]. Here I would like
to get your opinion on some of my thoughts regarding behavior of
resource-type-list, resource-type-show and template-validate with this new
features.

resource-type-list
We already (or soon will) hide unavailable in the cloud / for the user
resources from the listing. But what if we add an API flag e.g. --all to
show all registered in the engine resources? That would give any user a
glimpse of what their Orchestration service can manage in principle, so
they can nag the cloud operator to install additional OpenStack components
or give them required roles :)

resource-type-show
Right now the plan is to disable "showing" unavailable to the user
resources. But may be we should leave this as it is, for the same purpose
as above (or again add a --all flag or such)?

template-validate
Right now Heat is failing validation for templates containing resource
types not registered in the engine (e.g. typo). Should we also make this
call available services- and roles-sensitive? Or should we leave a way for
a user to check validity of any template with any in principle supported
resources?

The bottom line is we are good in making Heat service to be as much
self-documented via its own API as possible - let's keep doing that and
make any Heat deployment to be the Heat primer :)

Eager to hear your opinions.

[1]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html

[2]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html

Best regards,
 --
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

[Adrian Otto]

Peng,

On Jul 13, 2015, at 8:37 PM, Peng Zhao mailto:p...@hyper.sh>> 
wrote:

Thanks Adrian!

Hi, all,

Let me recap what is hyper and the idea of hyperstack.

Hyper is a single-host runtime engine. Technically,
Docker = LXC + AUFS
Hyper = Hypervisor + AUFS
where AUFS is the Docker image.

I do not understand the last line above. My understanding is that AUFS == 
UnionFS, which is used to implement a storage driver for Docker. Others exist 
for btrfs, and devicemapper. You select which one you want by setting an option 
like this:

DOCKEROPTS="-s devicemapper”

Are you trying to say that with Hyper, AUFS is used to provide layered Docker 
image capability that are shared by multiple hypervisor guests?

My guess is that you are trying to articulate that a host running Hyper is a 
1:1 substitute for a host running Docker, and will respond using the Docker 
remote API. This would result in containers running on the same host that have 
a superior security isolation than they would if LXC was used as the backend to 
Docker. Is this correct?

Due to the shared-kernel nature of LXC, Docker lacks of the necessary isolation 
in a multi-tenant CaaS platform, and this is what Hyper/hypervisor is good at.

And because of this, most CaaS today run on top of IaaS: 
https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/388x275/e286dea1266b46c1999d566b0f9e326b/iaas.png
Hyper enables the native, secure, bare-metal CaaS  
https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/395x244/828ad577dafb3f357e95899e962651b2/caas.png

From the tech stack perspective, Hyperstack turns Magnum o run in parallel with 
Nova, not running on atop.

For this to work, we’d expect to get a compute host from Heat, so if the bay 
type were set to “hyper”, we’d need to use a template that can produce a 
compute host running Hyper. How would that host be produced, if we do not get 
it from nova? Might it make more sense to make a dirt driver for nova that 
could produce a Hyper guest on a host already running the nova-compute agent? 
That way Magnum would not need to re-create any of Nova’s functionality in 
order to produce nova instances of type “hyper”.

Is Hyper compatible with libvirt?

Can Hyper support nested Docker containers within the Hyper guest?

Thanks,

Adrian Otto


Best,
Peng

-- Original --
From:  "Adrian 
Otto"mailto:adrian.o...@rackspace.com>>;
Date:  Tue, Jul 14, 2015 07:18 AM
To:  "OpenStack Development Mailing List (not for usage 
questions)"mailto:openstack-dev@lists.openstack.org>>;
Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper

Team,

I woud like to ask for your input about adding support for Hyper in Magnum:

https://blueprints.launchpad.net/magnum/+spec/hyperstack

We touched on this in our last team meeting, and it was apparent that achieving 
a higher level of understanding of the technology before weighing in about the 
directional approval of this blueprint. Peng Zhao and Xu Wang have graciously 
agreed to respond to this thread to address questions about how the technology 
works, and how it could be integrated with Magnum.

Please take a moment to review the blueprint, and ask your questions here on 
this thread.

Thanks,

Adrian Otto

On Jul 2, 2015, at 8:48 PM, Peng Zhao mailto:p...@hyper.sh>> 
wrote:

Here is the bp of Magnum+Hyper+Metal integration: 
https://blueprints.launchpad.net/magnum/+spec/hyperstack

Wanted to hear more thoughts and kickstart some brainstorming.

Thanks,
Peng

-
Hyper - Make VM run like Container


__
OpenStack Development Mailing List (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] [Congress] New IRC meeting time

[Tim Hinrichs]

To better accommodate the active contributors, we're moving our IRC meeting
to

2300 UTC = 4p Pacific = 7p Eastern
#openstack-meeting-3

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

Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master

[Adrian Otto]

On Jul 13, 2015, at 8:40 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:



From: "OTSUKA, Motohiro" mailto:yuany...@oeilvert.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 13, 2015 at 8:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates 
with k8s master

Hi, Wanghua

  Currently magnum-conductor can communicates with k8s master which has a 
floating ip in all-in-one deployment. But if magnum-conductor is not deployed 
on the neutron network node which has the br-ex, how can magnum-conductor 
communicate with k8s master. The magnum-conductor node then has no access to 
the k8s master.
Currently this is a limitation of our architecture.


The floating IP is a public routed network, so it should be able to communicate 
in a properly setup cloud.

  Another question:
  Magnum-conductor only communicate with k8s master, why k8s minion has a 
floating ip too? What is the floating ip of k8s minion used for?

I think, there is no reason.
Historically, Our heat template come from larsks/heat-kubernetes [1] template.
larsks/heat-kubernetes provides floating ip to minion nodes, this is just a 
reason.

The minion floating ips are needed to access the micro-service front ends from 
the internet.

To be clear, the actual requirement is that the minion nodes must be able to 
make TCP connections to the master node. Depending on the routing setup on your 
nodes, and the arrangement of your network, that could be possible without a 
floating ip on the minion nodes. With that in mind, having a publicly routable 
address (floating ip) on your minion node is one way to produce such 
connectivity.

I’m sure we would be open to a proposal that eliminates our requirement for the 
floating ip on the minion nodes that would work properly in various network 
environments.

Adrian


Regards
-steve



[1]: https://github.com/larsks/heat-kubernetes

Thanks
-Yuanying

__
OpenStack Development Mailing List (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] Time to remove Python2.6 jobs from master

[Joshua Harlow]

Ihar Hrachyshka wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/14/2015 01:46 AM, Perry, Sean wrote:

-Original Message- From: Doug Hellmann
[mailto:d...@doughellmann.com] Sent: Monday, July 13, 2015 3:41
PM To: openstack-dev Subject: Re: [openstack-dev] [all] Time to
remove Python2.6 jobs from master

Excerpts from Robert Collins's message of 2015-07-14 09:05:43
+1200:

On 14 July 2015 at 02:10, Jeremy Stanley
wrote:

On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote:
[...]

On the other hand, how much longer will we be supporting
Juno? A matter of months, right?

The reason it's being brought up again at this point is to
ask whether it's more important that we keep master
clients/libs working with 2.6 for several more months, or be
able to push forward with our constraints overhaul between
now and then. I'll be hard to have the necessary tooling in
place before the liberty release if we can't actually use it
before then (since that's roughly when juno EOL is
scheduled).

Additional detail: - generating 2.6 pins for global
requirements requires access to 2.6 where the periodic job runs
*and where devs are generating updates*. - so that means docker
or lxc or something in both the CI system and widely available
for devs.

So its a non-trivial impact; we can do it to move things
forward, but it would be a lot cheaper not to.

I don't *want* to keep 2.6 support around, and I do understand
that the requirements work will be made easier.  I'm just trying
to understand what other impact dropping it will have.


It will break RHEL 5 (maybe early 6 too) and older RH systems.
Ubuntu older than 9 I think (which is beyond unsupported). Not sure
about other Linux dists.

Basically if RHEL 5 is no longer a valid target and we are sure all
of the 6s have updated then let's nuke it from orbit.



I don't believe there was any release of RHEL-OSP that targeted RHEL
5. As for RHEL 6, the last version that got support for it was OSP5
which is based on Icehouse.

Speaking of RDO, there were attempts to get nova pieces of Juno
backported to RHEL 6 (mostly for CERN). Other than that, I don't think
anyone considers to run anything Kilo+ on RHEL 6, and it will probably
fail to work properly since a lot of underlying platform components in
RHEL 6 would be not ready for new features. (RHEL-OSP could
potentially get all the needed pieces in place, but there was a
decision not to go this route and instead require RHEL 7 for anything
Juno+).



Just a side-note, people have gotten kilo+ to run on RHEL6.x using 
virtualenvs and SCL python2.7 using http://anvil.readthedocs.org/ so 
it's not out of the realm of possible ;)


Not everyone can upgrade to RHEL7.x 'in a jiffy' when u have a large 
cloud with a ton of RHEL6.x hypervisors that people rely on, eventually 
it will happen, but not always so quickly ;)



Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVpMlOAAoJEC5aWaUY1u57aqMH/jUqVjZeYTFGIG5ncxU62IuU
Jenu/c5GaGiwMdU4dDG4x25hH6NRN3vNmbXE6oF5HrkbCq7oqih7IjoTI/3Wfo6U
Pwk951VU986duN8syxH+dINWZiOrZ8UNDgO2VI3Tn15TUG/S3eZtMTuM9BHoLn2K
cQYlqZrKQnKVK+zNHdZI7X58P728BNeWONUl5ry7mwOZcWDs7PzvsGJ1t8zrDsE4
sGT3QT3x9VCi+tVD17DW7ZuBA+W1oVtNp3RdDkIN5fsaSE0WDZPr9PPW6jIxHNKo
BP+GS7GPvqZEOK2A4I1foZg6tpkDYlxQo1D5Pz7Ep/9LIDahvE5EUQHRQoUPVH8=
=CuFo
-END PGP SIGNATURE-

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


__
OpenStack Development Mailing List (not 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] Should we document the using of "device:owner" of the PORT ?

[Salvatore Orlando]

Yes please.

This would be a good starting point.
I also think that the ability of editing it, as well as the value it could
be set to, should be constrained.

As you have surely noticed, there are several code path which rely on an
appropriate value being set in this attribute.
This means a user can potentially trigger malfunctioning by sending PUT
requests to edit this attribute.

Summarizing, I think that document its usage is a good starting point, but
I believe we should address the way this attribute is exposed at the API
layer as well.

Salvatore



On 13 July 2015 at 11:52, Wang, Yalei  wrote:

>  Hi all,
>
> The device:owner the port is defined as a 255 byte string, and is widely
> used now, indicating the use of the port.
> Seems we can fill it freely, and user also could update/set it from cmd
> line(port-update $PORT_ID --device_owner), and I don’t find the guideline
> for using.
>
> What is its function? For indicating the using of the port, and seems
> horizon also use it to show the topology.
> And nova really need it editable, should we at least document all of the
> possible values into some guide to make it clear? If yes, I can do it.
>
>
> I got these using from the code(maybe not complete, pls point it out):
>
> From constants.py,
> DEVICE_OWNER_ROUTER_HA_INTF = "network:router_ha_interface"
> DEVICE_OWNER_ROUTER_INTF = "network:router_interface"
> DEVICE_OWNER_ROUTER_GW = "network:router_gateway"
> DEVICE_OWNER_FLOATINGIP = "network:floatingip"
> DEVICE_OWNER_DHCP = "network:dhcp"
> DEVICE_OWNER_DVR_INTERFACE = "network:router_interface_distributed"
> DEVICE_OWNER_AGENT_GW = "network:floatingip_agent_gateway"
> DEVICE_OWNER_ROUTER_SNAT = "network:router_centralized_snat"
> DEVICE_OWNER_LOADBALANCER = "neutron:LOADBALANCER"
>
> And from debug_agent.py
> DEVICE_OWNER_NETWORK_PROBE = 'network:probe'
> DEVICE_OWNER_COMPUTE_PROBE = 'compute:probe'
>
> And setting from nova/network/neutronv2/api.py,
> 'compute:%s' % instance.availability_zone
>
>
> Thanks all!
>
> /Yalei
>
>
> __
> OpenStack Development Mailing List (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] A new BP - Support large datasets being passed

[ELISHA, Moshe (Moshe)]

Hey,

I have created a new BP "Support large datasets being passed" [1].
You comments / suggestion / approval are most welcome.

[1] - https://blueprints.launchpad.net/mistral/+spec/support-large-datasets
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][all] policy on approving constraint changes

[Jeremy Stanley]

On 2015-07-14 11:12:03 -0400 (-0400), Doug Hellmann wrote:
> At one point Robert proposed that we change the policy for approving
> constraint changes like https://review.openstack.org/#/c/201408/ to
> allow a single reviewer to approve it, assuming the tests were green.
> Is that our current policy, or are we waiting for the integration of
> constraints with our tox environments before deciding whether to make
> that change?

Since constraints are not being applied at all to tox-based jobs
currently (see the thread on dropping Python 2.6 in master
branches), approving updates to them has no chance to impact
tox-based jobs either positively or negatively. Also, they're really
just a manifestation of how pip's resolver interprets our
global-requirements.txt, which is what we should be more carefully
reviewing. Right now it's serving as a mechanism to keep
requirements pinned to a known-passing set in DevStack-based jobs,
and that is already determined by the jobs which report on the
constraints update itself.
-- 
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] [nova] Reminder: July 16 is non-priority feature proposal freeze

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/14/2015 05:52 AM, John Garbutt wrote:

> Please note, the non-priority feature freeze is on: July 30

Exception: subject and body not in agreement.

:)

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVpUl5AAoJEKMgtcocwZqL1aYP/31nEnOnCL2H2MDIo8SwmNQf
RLTRLPU1Z7fB/gMjvbf3vrfOwai4pX2UHyZWbni50gP7SSsX1keUlGygMsecpQ5t
XrHxONYIfQRoRQaE9z52d/01NzT0YhynecCB2bzuD/fAdXJLB+pZgsV3PB9K9eup
ZxwYy5r4A/0XzryvFls2CEl32ydEOcV+087FOUAtSQA4q7fSvPLSiDXtyMw+K3wc
4pD17G2h9Qar18Gv8IXkKMyeJm9v4PVGacciSkKn41+/taiaPc39CTEhyjRuIahO
KhxPoXgsakhdnFOEza7AEJ0sjNQhDfuIpwkI6zJUOyHXzLGuwA/5wKhusKoTFeCU
ExULenJF5xyhEVHZ1Ir8eSqIHuuNkGmLq6VSadiDdSydSQ21IkTW1oKcO8SHHv+8
HEPUYV6p2skpF2ebOfN2hV8QWrwWOA2IfaNPsb1jOCe75Tj7/P8mKP7THebaQhCe
2jVKUqWprqz0B29cDBABNqREDq32c0ny4N394vB0mbVwKjj3ChZz8vWha7BIsAmy
PKFKEMB70A8xinPFkR4XUhYnuiOz6dNX0kHqg0UV/16dkTcmAhUfS+1TCFq1KalZ
Baj7RZaN2PkhVOE6yvgHwUBrhSc64exSWcsEcYvd11YGRvvT+jBK4F/X5dX4rI9g
g/jswH5EvhrHyaf1nWtE
=LNTw
-END PGP SIGNATURE-

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

Re: [openstack-dev] [nova] Switching the bug status of ~200 bugs at once; Problem?

[Matt Riedemann]

On 7/14/2015 5:51 AM, Markus Zoeller wrote:

Markus Zoeller/Germany/IBM@IBMDE wrote on 07/10/2015 03:55

[...]


So you have a bunch of bugs that are Confirmed (or Triaged) + an
assignee set. I would argue that you need to separate two cases:

the bug had no activity for the last 60 days: assignee should be

removed


the bug had activity in the last 60 days: status should be "in

progress"


otherwise you further hide the fact that the bug is abandoned by

setting

status in addition to the assignee.

Cheers,

--
Thierry Carrez (ttx)


Right. My first intention was to switch all to "in progress" and then
switch a subset of that back to the previous status, depending on their
activity. I see now that this would cause confusion.
I'll process them seperately like Thierry suggested to avoid that
confusion. I'll announce the expected changes in the next days before
I actually execute them.

Regards,
Markus Zoeller (markus_z)


Here are the numbers. From the currently 215 "Confirmed" and "Triaged"
bugs which have an assignee (= inconsistency), there are:

  active  inactive
 -
 Triaged   4 5
 Confirmed57   149

"active" = there is a comment within the last 60 days in Launchpad
   - or -
the bug mentions at least one patch set in gerrit which is
* under review
* verified by Jenkins
* and without negative code reviews (older than 28 days)

"inactive" = the last update of the bug is older than 60 days
  - and -
  the bug mentions no active patch sets or only patch sets
  which have -1s which are not addressed for 28 days.

I'm not sure why the number of the inactive confirmed bugs is so big.
Could it be that this is a way to "bookmark" bugs where one wants to
work on in the future?

Below are the details of the "Confirmed" and "Triaged" bugs which would
be affected as soon as I run the mentioned script in 'active' mode.

Maybe a short note why I think that this could improve Nova: I assume
that the average turnaround time of the bugs, from their creation until
they get closed with appropriate patch sets, can be decreased if the
'stale' bugs get a regular cleanup to enable other contributers to work
on them.

I'll wait a week until I execute this to give you some time to speak up.


Details:


Legend:
---
 "=>In Progress": Switch the status of the bug to "In Progress"
 "-Assignee": Remove the current assignee
 "Age"  : Days since the last update (in LP or Gerrit)
 "Patch Set ...": A summary of a patch set in Gerrit. Constructed as:
 [review-id] (+2s +1s -1s -2s)
 (G:Jenkins Vote W:Workflow Flag) 

===
CleanUpReport(9 Items): 'Triaged' bugs with an assignee
===
Bug ID  Title  Age Contributer  Cleanup Action

---
1467409 HyperV destroy vm fails on Wi[...]  21 Adelina Tuve =>In Progress

1177570 Hyper-V tests can be refactor[...] 368 Alessandro P -Assignee
1355171 Can not have IPv4 or IPv6 onl[...]  91 Chris Gacsal -Assignee
1412480 Hyper-V: Instance booted from[...] 175 Claudiu Belu -Assignee
1458013 ec2 code uses requests to tal[...]  29 Deepti Ramak =>In Progress

1436079 There is no API samples funct[...] 103 Eli Qiao -Assignee
1458934 Ironic: heavy polling   25 Lucas Alvare =>In Progress

1441361 Don't trace on InstanceInfoCa[...]  96 Matt Riedema -Assignee
1415087 [OSSA 2015-011] Format-guessi[...]   7 Tony Breeds  =>In Progress

---
 4 x =>In Progress
 5 x -Assignee
===


===
CleanUpReport(206 Items): 'Confirmed' bugs with an assignee
===
Bug ID  Title  Age Contributer  Cleanup Action

---
1309184 nova should delete neutron po[...] 305 Aaron Rosen  -Assignee
1265447 floating-ip-bulk-delete metho[...] 151 Abhishek Tal -Assignee
1301368 Hyper-V configdrive is not at[...] 105 Adrian Vladu -Assignee
1335784 remove secgroup rule won't cu[...] 305 Akash Gangil -Assignee
1153842 nova volume-attach  In Progress

1301532 Quotas can be exceeded by mak[...]  90 Alex Xu  -Assignee
 Patch Set: [110863] (2 1 0 0) (G:0 W:None) age(d):341 - MERGED
1443494 Return supported micro-versio[...]  69 Alex Xu  -Assignee
1253571 libivrt+xen does not support [...] 334 Alvaro Lopez -Assignee
1410651 wrong output when trying to d

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Jain, Vivek]

Thanks Akihiro. Currently lbaas panels are part of horizon repo. If there is a 
easy way to de-couple lbaas dashboard from horizon? I think that will simplify 
development efforts. What does it take to separate lbaas dashboard from horizon?

Thanks,
Vivek

From: Akihiro Motoki mailto:amot...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 10:09 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Balle, Susanne" mailto:susanne.ba...@hp.com>>, 
"Tonse, Milan" mailto:mto...@ebay.com>>
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Another option is to create a project under openstack.
designate-dashboard project takes this approach,
and the core team of the project is both horizon-core and designate-core.
We can do the similar approach. Thought?

I have one question.
Do we have a separate place forever or do we want to merge horizon repo
once the implementation are available.
If we have a separate repo for LBaaS v2 panel, we need to release it separately.

I am not sure I am available at LBaaS meeting, but I would like to help
this efforts as a core from horizon and neutron.

Akihiro


2015-07-15 1:52 GMT+09:00 Doug Wiegley 
mailto:doug...@parksidesoftware.com>>:
I’d be good submitting it to the neutron-lbaas repo, under a horizon/ 
directory. We can iterate there, and talk with the Horizon team about how best 
to integrate. Would that work?

Thanks,
doug

> On Jul 13, 2015, at 3:05 PM, Jain, Vivek 
> mailto:vivekj...@ebay.com>> wrote:
>
> Hi German,
>
> We integrated UI with LBaaS v2 GET APIs. We have created all panels for
> CREATE and UPDATE as well.
> Plan is to share our code with community on stackforge for more
> collaboration from the community.
>
> So far Ganesh from cisco has shown interest in helping with some work. It
> will be great if we can get more hands.
>
> Q: what is the process for hosting in-progress project on stackforge? Can
> someone help me here?
>
> Thanks,
> Vivek
>
> On 7/10/15, 11:40 AM, "Eichberger, German" 
> mailto:german.eichber...@hp.com>>
> wrote:
>
>> Hi Vivek,
>>
>> Hope things are well. With the Midccyle next week I am wondering if you
>> made any progress and/or how we can best help with the panels.
>>
>> Thanks,
>> German
>>
>> From: "Jain, Vivek" 
>> mailto:vivekj...@ebay.com>>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-dev@lists.openstack.org>
>> g>>
>> Date: Wednesday, April 8, 2015 at 3:32 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-dev@lists.openstack.org>
>> g>>
>> Cc: "Balle Balle, Susanne"
>> mailto:susanne.ba...@hp.com>>>,
>>  "Tonse, Milan"
>> mailto:mto...@ebay.com>>>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
>> neutron-lbaas v2
>>
>> Thanks German for the etherpad link. If you have any documentation for
>> flows, please share those too.
>>
>> I will work with my team at ebay to publish wireframes for design we are
>> working on. It will be mostly along the lines I demo’ed in Paris.
>>
>> Thanks,
>> Vivek
>>
>> From: , German
>> mailto:german.eichber...@hp.com>>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-dev@lists.openstack.org>
>> g>>
>> Date: Wednesday, April 8, 2015 at 11:24 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-dev@lists.openstack.org>
>> g>>
>> Cc: "Balle, Susanne" 
>> mailto:susanne.ba...@hp.com>>>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
>> neutron-lbaas v2
>>
>> Hi,
>>
>> We briefly talked about it a few Neutron meetings back (LBaaS is now on
>> demand) and created an etherpad to track things:
>> https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases
>>
>> Susanne and I met with HP’s UX designer to work on the design for some
>> flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the
>> lead. Please check that etherpad for more information and feel free to
>> update as things happen…
>>
>> Thanks,
>> German
>>
>>
>> From: Jain, Vivek [mailto:vivekj...@ebay.com]
>> Sent: Tuesday, April 07, 2015 9:01 AM
>> To: OpenStack Development Mailing 

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Jain, Vivek]

1600utc on Thursday (9am PDT  Thursday) works for me. Can we use 
#openstack-lbaas channel ?

I have committed under development lbaas v2 horizon code to my public github 
and will move it to neutron-lbaas: https://github.com/openstack/neutron-lbaas

Thanks,
Vivek

From: Doug Wiegley 
mailto:doug...@parksidesoftware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 9:53 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "Balle, Susanne" mailto:susanne.ba...@hp.com>>, 
"Tonse, Milan" mailto:mto...@ebay.com>>
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas 
v2

Can we setup a short IRC meeting to sync up on details?  1600utc on thursday, 
maybe? Other?

Thanks,
doug

On Jul 13, 2015, at 4:02 PM, Praveen Yalagandula 
mailto:yprav...@avinetworks.com>> wrote:

Hi Vivek,

I can help on this effort. Thanks for leading this!

We had done some work to add "Certificates" support to the current loadbalancer 
panel, which we put out for public access at 
https://github.com/avinetworks/avi-horizon-dashboard. Essentially, this adds a 
"Certificates" tab to manage SSL certificates (though currently the code 
communicates with our controller, but could be changed to invoke Barbican 
APIs), and also adds "Associate Cert" and "Disassociate Cert" to the current 
pool drop down links (see the images below). Note that we did this way as v1.0 
APIs did not have support for certificates, and we implement 
associate/disassociate by having Horizon talk directly to the our controller.

Cheers,
Praveen




On Mon, Jul 13, 2015 at 2:05 PM, Jain, Vivek 
mailto:vivekj...@ebay.com>> wrote:
Hi German,

We integrated UI with LBaaS v2 GET APIs. We have created all panels for
CREATE and UPDATE as well.
Plan is to share our code with community on stackforge for more
collaboration from the community.

So far Ganesh from cisco has shown interest in helping with some work. It
will be great if we can get more hands.

Q: what is the process for hosting in-progress project on stackforge? Can
someone help me here?

Thanks,
Vivek

On 7/10/15, 11:40 AM, "Eichberger, German" 
mailto:german.eichber...@hp.com>>
wrote:

>Hi Vivek,
>
>Hope things are well. With the Midccyle next week I am wondering if you
>made any progress and/or how we can best help with the panels.
>
>Thanks,
>German
>
>From: "Jain, Vivek" 
>mailto:vivekj...@ebay.com>>>
>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>mailto:openstack-dev@lists.openstack.org>
>g>>
>Date: Wednesday, April 8, 2015 at 3:32 PM
>To: "OpenStack Development Mailing List (not for usage questions)"
>mailto:openstack-dev@lists.openstack.org>
>g>>
>Cc: "Balle Balle, Susanne"
>mailto:susanne.ba...@hp.com>>>,
> "Tonse, Milan"
>mailto:mto...@ebay.com>>>
>Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
>neutron-lbaas v2
>
>Thanks German for the etherpad link. If you have any documentation for
>flows, please share those too.
>
>I will work with my team at ebay to publish wireframes for design we are
>working on. It will be mostly along the lines I demo’ed in Paris.
>
>Thanks,
>Vivek
>
>From: , German
>mailto:german.eichber...@hp.com>>>
>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>mailto:openstack-dev@lists.openstack.org>
>g>>
>Date: Wednesday, April 8, 2015 at 11:24 AM
>To: "OpenStack Development Mailing List (not for usage questions)"
>mailto:openstack-dev@lists.openstack.org>
>g>>
>Cc: "Balle, Susanne" 
>mailto:susanne.ba...@hp.com>>>
>Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
>neutron-lbaas v2
>
>Hi,
>
>We briefly talked about it a few Neutron meetings back (LBaaS is now on
>demand) and created an etherpad to track things:
>https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases
>
>Susanne and I met with HP’s UX designer to work on the design for some
>flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the
>lead. Please check that etherpad for more information and feel free to
>update as things happen…
>
>Thanks,
>German
>
>
>From: Jain, Vivek [mailto:vivekj...@ebay.com]
>Sent: Tuesday, April 07, 2015 9:01 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subjec

[openstack-dev] [app-catalog] IRC Meeting Thursday July 16th at 17:00UTC

[Christopher Aedo]

(Apologies for the re-send, missed the appropriate tag on the subject line!)

Hello! Our next OpenStack App Catalog meeting will take place this
Thursday July 16th at 17:00 UTC in #openstack-meeting-3

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

Please add agenda items if there's anything specific you would like to
discuss.  For this weeks meeting my primary intention is to discuss
the roadmap, everything we'd like to accomplish before the next
summit, and determine who all will be helping get it done.

Please join us if you can!

__
OpenStack Development Mailing List (not 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] Horizon support for neutron-lbaas v2

[Akihiro Motoki]

Another option is to create a project under openstack.
designate-dashboard project takes this approach,
and the core team of the project is both horizon-core and designate-core.
We can do the similar approach. Thought?

I have one question.
Do we have a separate place forever or do we want to merge horizon repo
once the implementation are available.
If we have a separate repo for LBaaS v2 panel, we need to release it
separately.

I am not sure I am available at LBaaS meeting, but I would like to help
this efforts as a core from horizon and neutron.

Akihiro


2015-07-15 1:52 GMT+09:00 Doug Wiegley :

> I’d be good submitting it to the neutron-lbaas repo, under a horizon/
> directory. We can iterate there, and talk with the Horizon team about how
> best to integrate. Would that work?
>
> Thanks,
> doug
>
> > On Jul 13, 2015, at 3:05 PM, Jain, Vivek  wrote:
> >
> > Hi German,
> >
> > We integrated UI with LBaaS v2 GET APIs. We have created all panels for
> > CREATE and UPDATE as well.
> > Plan is to share our code with community on stackforge for more
> > collaboration from the community.
> >
> > So far Ganesh from cisco has shown interest in helping with some work. It
> > will be great if we can get more hands.
> >
> > Q: what is the process for hosting in-progress project on stackforge? Can
> > someone help me here?
> >
> > Thanks,
> > Vivek
> >
> > On 7/10/15, 11:40 AM, "Eichberger, German" 
> > wrote:
> >
> >> Hi Vivek,
> >>
> >> Hope things are well. With the Midccyle next week I am wondering if you
> >> made any progress and/or how we can best help with the panels.
> >>
> >> Thanks,
> >> German
> >>
> >> From: "Jain, Vivek" mailto:vivekj...@ebay.com>>
> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> >>  openstack-...@lists.openstack.or
> >> g>>
> >> Date: Wednesday, April 8, 2015 at 3:32 PM
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >>  openstack-...@lists.openstack.or
> >> g>>
> >> Cc: "Balle Balle, Susanne"
> >> mailto:susanne.ba...@hp.com>>, "Tonse, Milan"
> >> mailto:mto...@ebay.com>>
> >> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
> >> neutron-lbaas v2
> >>
> >> Thanks German for the etherpad link. If you have any documentation for
> >> flows, please share those too.
> >>
> >> I will work with my team at ebay to publish wireframes for design we are
> >> working on. It will be mostly along the lines I demo’ed in Paris.
> >>
> >> Thanks,
> >> Vivek
> >>
> >> From: , German
> >> mailto:german.eichber...@hp.com>>
> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> >>  openstack-...@lists.openstack.or
> >> g>>
> >> Date: Wednesday, April 8, 2015 at 11:24 AM
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >>  openstack-...@lists.openstack.or
> >> g>>
> >> Cc: "Balle, Susanne" mailto:susanne.ba...@hp.com
> >>
> >> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
> >> neutron-lbaas v2
> >>
> >> Hi,
> >>
> >> We briefly talked about it a few Neutron meetings back (LBaaS is now on
> >> demand) and created an etherpad to track things:
> >> https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases
> >>
> >> Susanne and I met with HP’s UX designer to work on the design for some
> >> flows for the Horizon panel (cc’d) but I am glad that Vivek is taking
> the
> >> lead. Please check that etherpad for more information and feel free to
> >> update as things happen…
> >>
> >> Thanks,
> >> German
> >>
> >>
> >> From: Jain, Vivek [mailto:vivekj...@ebay.com]
> >> Sent: Tuesday, April 07, 2015 9:01 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
> >> neutron-lbaas v2
> >>
> >> Hi Evgeny,
> >> We have just started working on Horizon lbaasv2 support. I have to sync
> >> up with my team on the time-line but it is not targeted for Kilo
> release.
> >> Since it is a major effort, we will need more hands. Let me know if
> >> anyone is interested to contribute.
> >>
> >> On a related note, Do we have a sample code which uses neutronclient
> >> lbaas v2 methods? That will greatly speedup our horizon integration.
> >>
> >> Thanks,
> >> Vivek
> >>
> >> From: Phillip Toohill
> >> mailto:phillip.tooh...@rackspace.com>>
> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> >>  openstack-...@lists.openstack.or
> >> g>>
> >> Date: Tuesday, April 7, 2015 at 7:50 AM
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >>  openstack-...@lists.openstack.or
> >> g>>
> >> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
> >> neutron-lbaas v2
> >>
> >>
> >> ​Hey Evgeny,
> >>
> >>
> >>
> >> I believe Vivek is working on Horizon lbaasv2 support. We werent given a
> >> timeline or anything but sounds like its being actively worked on. I
> >> would reach out to him to get better timelines if concerned.
> >>
> >>
> >> Phillip V. Toohill

[openstack-dev] [Senlin] TOSCA Reference Material

[Julio E Ruano]

Hi All,

I just wanted to share where all of the TOSCA reference material is 
accessible. It is maintained through an OASIS TC here -> 
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca 

The latest relevant spec is available here -> 
https://www.oasis-open.org/committees/download.php/56070/TOSCA-Simple-Profile-YAML-v1.0-wd06-rev05.docx
 


Of immediate synergy with Senlin is probably the discussion around 
policies starting on page #240 of the spec. Much of this is still in the 
definition stage, so there is opportunity to have Senlin influence the 
spec as well as to allow Senlin to adopt some of the definitions within 
the spec.

Regards,

- Julio__
OpenStack Development Mailing List (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] Meeting Thursday July 16th at 17:00UTC

[Christopher Aedo]

Hello! Our next OpenStack App Catalog meeting will take place this
Thursday July 16th at 17:00 UTC in #openstack-meeting-3

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

Please add agenda items if there's anything specific you would like to
discuss.  For this weeks meeting my primary intention is to discuss
the roadmap, everything we'd like to accomplish before the next
summit, and determine who all will be helping get it done.

Please join us if you can!

__
OpenStack Development Mailing List (not 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.messaging][zeromq] Next step

[Alec Hothan (ahothan)]

inline...


On 7/8/15, 8:23 AM, "Bogdan Dobrelya"  wrote:

>>> On 6/12/15, 3:55 PM, "Clint Byrum"  wrote:
>>> 
>>> >
>>> >> 
>>> >
>>> >I think you missed "it is not tested in the gate" as a root cause for
>>> >some of the ambiguity. Anecdotes and bug reports are super important
>>>for
>>> >knowing where to invest next, but a test suite would at least
>>>establish a
>>> >base line and prevent the sort of thrashing and confusion that comes
>>>from
>>> >such a diverse community of users feeding bug reports into the system.
>>> 
>>> I agree with you that zmq needs to pass whatever oslo messaging test is
>>> currently available however this won't remove all the
>>> semantical/behavioral ambiguities.
>>> This kind of ambiguities could be fixed by enhancing the API
>>>documentation
>>> - always good to do even if a bit late - and by developing the
>>>associated
>>> test cases (although they tend to be harder to write).
>>> Another (ugly) strategy could be to simply say that the intended
>>>behavior
>>> is the one exposed by the rabbitMQ based implementation (by means of
>>> seniority and/or actual deployment mileage).
>>> 
>>> For example, what happens if a recipient of a CALL or CAST message dies
>>> before the message is sent.
>>> Is the API supposed to return an error and if yes how quickly? RabbitMQ
>>> based implementation will
>>> likely return a success (since the message will sit in a queue in the
>>> broker until the consumer reconnects - which could be a long time)
>>>while
>>> ZMQ based will depend on the type of pattern used. Which is the
>>>behavior
>>> desired by apps and which is the behavior "advertised" by the oslo
>>> messaging API?
>>> 
>>> Another example relates to flow control conditions (sender sends lots
>>>of
>>> CAST, receiver very slow to consume). Should the sender
>>> - always receive success and all messages will be queued without limit,
>>> - always receive success and all messages will be queued up to a
>>>certain
>>> point and new messages will be dropped silently
>>> - or receive an EAGAIN error (socket behavior)?
>>> 
>>> In these unclear conditions, switching to a different transport driver
>>>is
>>> going to be tricky because apps may have been written/patched to
>>>assume a
>>> certain behavior and might no longer behave properly if the expected
>>> behavior changes (even if it is for the better) and may require
>>>adjusting
>>> existing apps (to support a different behavior of the API).
>>> Note that "switching to a different transport" is not just about
>>>testing
>>> it in devstack but also about deploying it at scale on real production
>>> environment and testing at scale.
>> 
>> Alec, you bring up fantastic and importan points above.
>> 
>> However, lets stay on track. We're not even testing to see if nova-api
>> can talk to nova-conductor via the current zmq driver. It's entirely
>> possible it simply does not work for any number of reasons.
>> 
>> A devstack-gate job is the _minimum_ needed.
>
>I believe the next steps can be summarized as the following:
>
>1) Make existing zeromq driver tested in the gate in order to save it
>from deprecation and removal.

I believe Oleksii is already working on it.


>
>2) Think of the new driver architecture decisions more precisely, like:
>- synchronous blocking REQ/REP or async DEALER/ROUTER for CALLs
>- at-least-once delivery (confirms after processing) or at-most-once
>(confirms before processing)
>- do we want fault tolerant CALL and/or CAST, NOTIFY (AFAIK, zeromq
>supports HA only for REQ/REP, ROUTER/DEALER)
>- idempotent/commutative operations or ordered and non-idempotent

On all above I believe it is best to keep oslo messaging simple and
predictable, then have apps deal with any retry logic as it is really app
specific.
Auto retries in oslo messaging can cause confusion with possible
duplicates which could be really bad if the messages are not idempotent.
I think trying to make oslo messaging a complex communication API is not
realistic with the few resources available.
It is much better to have something simple that works well (even that is
not easy as we can see) than something complex that has lots of issues.


>- event based notifications on changes in the numbers of clients and
>servers (affects the discovery service very much)
>- routing proxies and discovery service backends

Yes I'd like to help on that part.

>
>3) Address all of the ambiguities of the API documentation in order to
>keep messaging library developers and apps developers "at the same
>page". This is a vital step as the new driver -as well as the existing
>ones- have to rely on well known and clearly described expectations and
>behave appropriately.

I'm glad to see more people converging on this shortcoming and the need to
do something.

As I said above, I would keep the oslo messaging API straight and simple
and predictable.
The issue with that is it may make the AMQP driver non compliant as it may
be doing too much already but we can try to work 

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Doug Wiegley]

Can we setup a short IRC meeting to sync up on details?  1600utc on thursday, 
maybe? Other?

Thanks,
doug

> On Jul 13, 2015, at 4:02 PM, Praveen Yalagandula  
> wrote:
> 
> Hi Vivek,
> 
> I can help on this effort. Thanks for leading this!
> 
> We had done some work to add "Certificates" support to the current 
> loadbalancer panel, which we put out for public access at 
> https://github.com/avinetworks/avi-horizon-dashboard 
> . Essentially, this 
> adds a "Certificates" tab to manage SSL certificates (though currently the 
> code communicates with our controller, but could be changed to invoke 
> Barbican APIs), and also adds "Associate Cert" and "Disassociate Cert" to the 
> current pool drop down links (see the images below). Note that we did this 
> way as v1.0 APIs did not have support for certificates, and we implement 
> associate/disassociate by having Horizon talk directly to the our controller.
> 
> Cheers,
> Praveen
> 
> 
> 
> 
> On Mon, Jul 13, 2015 at 2:05 PM, Jain, Vivek  > wrote:
> Hi German,
> 
> We integrated UI with LBaaS v2 GET APIs. We have created all panels for
> CREATE and UPDATE as well.
> Plan is to share our code with community on stackforge for more
> collaboration from the community.
> 
> So far Ganesh from cisco has shown interest in helping with some work. It
> will be great if we can get more hands.
> 
> Q: what is the process for hosting in-progress project on stackforge? Can
> someone help me here?
> 
> Thanks,
> Vivek
> 
> On 7/10/15, 11:40 AM, "Eichberger, German"  >
> wrote:
> 
> >Hi Vivek,
> >
> >Hope things are well. With the Midccyle next week I am wondering if you
> >made any progress and/or how we can best help with the panels.
> >
> >Thanks,
> >German
> >
> >From: "Jain, Vivek"  > >>>
> >Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> > > > 
> >g>>
> >Date: Wednesday, April 8, 2015 at 3:32 PM
> >To: "OpenStack Development Mailing List (not for usage questions)"
> > > > 
> >g>>
> >Cc: "Balle Balle, Susanne"
> > > >>>, "Tonse, Milan"
> >mailto:mto...@ebay.com> >>>
> >Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
> >neutron-lbaas v2
> >
> >Thanks German for the etherpad link. If you have any documentation for
> >flows, please share those too.
> >
> >I will work with my team at ebay to publish wireframes for design we are
> >working on. It will be mostly along the lines I demo’ed in Paris.
> >
> >Thanks,
> >Vivek
> >
> >From: , German
> > > >>>
> >Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> > > > 
> >g>>
> >Date: Wednesday, April 8, 2015 at 11:24 AM
> >To: "OpenStack Development Mailing List (not for usage questions)"
> > > > 
> >g>>
> >Cc: "Balle, Susanne"  > >>>
> >Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
> >neutron-lbaas v2
> >
> >Hi,
> >
> >We briefly talked about it a few Neutron meetings back (LBaaS is now on
> >demand) and created an etherpad to track things:
> >https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases 
> >
> >
> >Susanne and I met with HP’s UX designer to work on the design for some
> >flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the
> >lead. Please check that etherpad for more information and feel free to
> >update as things happen…
> >
> >Thanks,
> >German
> >
> >
> >From: Jain, Vivek [mailto:vivekj...@ebay.com ]
> >Sent: Tuesday, April 07, 2015 9:01 AM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
> >neutron-lbaas v2
> >
> >Hi Evgeny,
> >We have just started working on Horizon lbaasv2 support. I have to sync
> >up with my team on the time-line but it is not targeted for Kilo release.
> >Since it is a major effort, we will need more hands. Let me know if
> >anyone is interested to contribute.
> >
> >On a related note, Do we have a sampl

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

[Doug Wiegley]

I’d be good submitting it to the neutron-lbaas repo, under a horizon/ 
directory. We can iterate there, and talk with the Horizon team about how best 
to integrate. Would that work?

Thanks,
doug

> On Jul 13, 2015, at 3:05 PM, Jain, Vivek  wrote:
> 
> Hi German,
> 
> We integrated UI with LBaaS v2 GET APIs. We have created all panels for
> CREATE and UPDATE as well.
> Plan is to share our code with community on stackforge for more
> collaboration from the community.
> 
> So far Ganesh from cisco has shown interest in helping with some work. It
> will be great if we can get more hands.
> 
> Q: what is the process for hosting in-progress project on stackforge? Can
> someone help me here?
> 
> Thanks,
> Vivek
> 
> On 7/10/15, 11:40 AM, "Eichberger, German" 
> wrote:
> 
>> Hi Vivek,
>> 
>> Hope things are well. With the Midccyle next week I am wondering if you
>> made any progress and/or how we can best help with the panels.
>> 
>> Thanks,
>> German
>> 
>> From: "Jain, Vivek" mailto:vivekj...@ebay.com>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-...@lists.openstack.or
>> g>>
>> Date: Wednesday, April 8, 2015 at 3:32 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-...@lists.openstack.or
>> g>>
>> Cc: "Balle Balle, Susanne"
>> mailto:susanne.ba...@hp.com>>, "Tonse, Milan"
>> mailto:mto...@ebay.com>>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
>> neutron-lbaas v2
>> 
>> Thanks German for the etherpad link. If you have any documentation for
>> flows, please share those too.
>> 
>> I will work with my team at ebay to publish wireframes for design we are
>> working on. It will be mostly along the lines I demo’ed in Paris.
>> 
>> Thanks,
>> Vivek
>> 
>> From: , German
>> mailto:german.eichber...@hp.com>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-...@lists.openstack.or
>> g>>
>> Date: Wednesday, April 8, 2015 at 11:24 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-...@lists.openstack.or
>> g>>
>> Cc: "Balle, Susanne" mailto:susanne.ba...@hp.com>>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
>> neutron-lbaas v2
>> 
>> Hi,
>> 
>> We briefly talked about it a few Neutron meetings back (LBaaS is now on
>> demand) and created an etherpad to track things:
>> https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases
>> 
>> Susanne and I met with HP’s UX designer to work on the design for some
>> flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the
>> lead. Please check that etherpad for more information and feel free to
>> update as things happen…
>> 
>> Thanks,
>> German
>> 
>> 
>> From: Jain, Vivek [mailto:vivekj...@ebay.com]
>> Sent: Tuesday, April 07, 2015 9:01 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
>> neutron-lbaas v2
>> 
>> Hi Evgeny,
>> We have just started working on Horizon lbaasv2 support. I have to sync
>> up with my team on the time-line but it is not targeted for Kilo release.
>> Since it is a major effort, we will need more hands. Let me know if
>> anyone is interested to contribute.
>> 
>> On a related note, Do we have a sample code which uses neutronclient
>> lbaas v2 methods? That will greatly speedup our horizon integration.
>> 
>> Thanks,
>> Vivek
>> 
>> From: Phillip Toohill
>> mailto:phillip.tooh...@rackspace.com>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-...@lists.openstack.or
>> g>>
>> Date: Tuesday, April 7, 2015 at 7:50 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> mailto:openstack-...@lists.openstack.or
>> g>>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
>> neutron-lbaas v2
>> 
>> 
>> ​Hey Evgeny,
>> 
>> 
>> 
>> I believe Vivek is working on Horizon lbaasv2 support. We werent given a
>> timeline or anything but sounds like its being actively worked on. I
>> would reach out to him to get better timelines if concerned.
>> 
>> 
>> Phillip V. Toohill III
>> Software Developer
>> [http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rack
>> cdn.com/signatures/images/rackspace_logo.png]
>> phone: 210-312-4366
>> mobile: 210-440-8374
>> 
>> 
>> From: Evgeny Fedoruk mailto:evge...@radware.com>>
>> Sent: Tuesday, April 7, 2015 5:50 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [neutron][lbaas] Horizon support for
>> neutron-lbaas v2
>> 
>> Hi guys,
>> 
>> LBaaS v2 has no horizon support as for now and I want to know if this
>> work is planned to be done and , if yes, in what time frame.
>> Is there a plan to develop it for Kilo or for L release?
>> 
>> Thanks,
>> Evg
>> ___

Re: [openstack-dev] [magnum] Magnum Midcycle Event Scheduling Doodle Poll closes July 7th

[Adrian Otto]

Team,

Thanks everyone for your feedback. The Magnum Midcycle for the Liberty release 
will be held on 2015-08-05 and 2015-08-06. I look forward to seeing you all 
there.

Regards,

Adrian Otto

On Jul 1, 2015, at 11:03 AM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:

Apologies for double post – left off [magnum] prior by error.

Ton Ngo of IBM Silicon Valley Research has graciously offered to host the 2 day 
Magnum midcycle event at IBM’s facilities.

The sessions will run from 9AM – 5PM and catered lunch and refreshments 
(soda/water) will be provided.

The mid-cycle will be a standard mid-cycle with a 1 hour introduction followed 
by two days of design sessions.

Please cast your votes on any days you can make.

http://doodle.com/pinkuc5hw688zhxw

There are ~25 seats available.  Preference will be given to in-person core 
reviewers, followed by any folks that have made commits to the repository.  
After dates are settled, a separate eventbrite event will be setup to sort out 
the specifics such as  dietary needs, etc and confirm in-person seating if we 
are past capacity limits.

We will make remote participation available, but the experience will likely be 
less then optimal for remote participants.

Regards
-steve


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

Re: [openstack-dev] [puppet] First Sprint proposal

[Emilien Macchi]

We decided during our weekly meeting that the Sprint will happen
virtually on IRC on Wed 9/2 – Fri 9/4.

We will use #openstack-sprint (freenode) IRC channel and Google Hangout
/ Bluejeans if needed.

We made progress on defining an agenda:
https://etherpad.openstack.org/p/puppet-liberty-mid-cycle

Please have a look and feel free to add / complete the topics.

See you there,

On 07/13/2015 09:03 AM, Emilien Macchi wrote:
> I just closed the poll after one week.
> It will happen on Wed 9/2 – Fri 9/4.
> 
> We'll work on the agenda during the following weeks.
> 
> Best,
> 
> On 07/06/2015 10:26 PM, Matt Fischer wrote:
>> Operators mid-cycle is Aug 17-21 at a TBD location, I voted accordingly.
>> Thanks.
>>
>> On Mon, Jul 6, 2015 at 12:09 PM, Emilien Macchi > > wrote:
>>
>>
>>
>> On 07/06/2015 02:05 PM, Matt Fischer wrote:
>> > I think this is a great idea. I'd like to get a firm date on the
>> > operators mid-cycle before I vote though.
>>
>> If it overlaps, we can add more slots. Feel free to ping me on IRC for
>> that, I'll update the doodle.
>>
>> Thanks,
>>
>> >
>> > On Mon, Jul 6, 2015 at 11:31 AM, Emilien Macchi > 
>> > >> wrote:
>> >
>> > Hi,
>> >
>> > I would like to organize our first sprint for contributing to our 
>> Puppet
>> > OpenStack modules. It will happen in Red Hat Montreal (Canada) 
>> office,
>> > during 3 days.
>> >
>> > If you're interested to participate, please find the slots that 
>> may work
>> > for you [1]. Any slot suggestion is welcome though.
>> > Also, please bring on the etherpad any topics we should work on 
>> together
>> > [2].
>> > We will groom topics during a meeting and prepare the agenda 
>> before the
>> > sprint.
>> >
>> > [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k
>> > [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
>> >
>> > Regards,
>> > --
>> > Emilien Macchi
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> >   
>>  
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> >
>> 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> --
>> Emilien Macchi
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (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
> 

-- 
Emilien Macchi



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

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

[Emilien Macchi]

On 07/13/2015 09:23 AM, Emilien Macchi wrote:
> Hello Puppet masters!
> 
> Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
> in #openstack-meeting-4:
> 
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150714
> 
> Please add additional items you'd like to discuss.
> If our schedule allows it, we'll make bug triage during the meeting.
> 
> See you there!
> 

We did our meeting, you can read the notes here:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150714

Have a great day!

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

-- 
Emilien Macchi



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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Paul Bourke]

Thanks very much all it's a privilege. Look forward to continuing to 
help out as much as possible; please feel free to drop me a line on IRC 
or email any time.


-Paul

On 14/07/15 17:01, Steven Dake (stdake) wrote:

Well that is unanimous.  Welcome to the core team Paul!

Regards
-steve


From: "Daneyon Hansen (danehans)" mailto:daneh...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 8:56 AM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core


+1

From: "Steven Dake (stdake)" mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage
questions)" mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 13, 2015 at 7:40 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team.  He did a
fantastic job getting Kolla into shape to support multiple
distros and from source/from binary installation.  His
statistics are fantastic including both code and reviews.  His
reviews are not only voluminous, but consistently good.  Paul is
helping on many fronts and I would feel make a fantastic
addition to our core reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1.  A –1
vote is a veto for the candidate, so if you are on the fence,
best to abstain :)  We require 3 core reviewer votes to approve
a candidate.  I will leave the voting open until July 20th 
UTC.  If the vote is unanimous prior to that time or a veto vote
is received, I’ll close voting and make appropriate adjustments
to the gerrit groups.

Regards
-steve



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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Steven Dake (stdake)]

Well that is unanimous.  Welcome to the core team Paul!

Regards
-steve


From: "Daneyon Hansen (danehans)" 
mailto:daneh...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, July 14, 2015 at 8:56 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core


+1

From: "Steven Dake (stdake)" mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 13, 2015 at 7:40 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team.  He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation.  His statistics are fantastic including both code and 
reviews.  His reviews are not only voluminous, but consistently good.  Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote is a veto 
for the candidate, so if you are on the fence, best to abstain :)  We require 3 
core reviewer votes to approve a candidate.  I will leave the voting open until 
July 20th  UTC.  If the vote is unanimous prior to that time or a veto vote 
is received, I’ll close voting and make appropriate adjustments to the gerrit 
groups.

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

Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?

[Silvan Kaiser]

Thanks for the hint, Ramy!
I did talk about this a longer time ago in the 3rdParty weekly but it was
hard to for people to help as it was an issue quite specific to our setup.
On other occasions, however, that meeting has been greatly helpful and I
recommend it, too!
Silvan


2015-07-07 6:01 GMT+02:00 Asselin, Ramy :

>  HI Silvan,
>
>
>
> A great resource to resolve such issues is the third-party ci meetings
> [1]. It’s a dedicated time slot to ask questions and get help from other
> community members such as yourself. Oftentimes, someone else has run into
> the same issue and already as an answer.
>
>
>
> Ramy
>
>
>
> [1] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
>
>
>
>
> *From:* Silvan Kaiser [mailto:sil...@quobyte.com]
> *Sent:* Friday, July 03, 2015 9:06 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?
>
>
>
> Hello again!
>
> Ok, now i did find the review [1], sorry i did not earlier.
>
>
>
> We will solve the CI issues asap in order to provide the requirements to
> recommit the Quobyte driver.
>
> We've been trying to solve the CIs networking issue i wrote about since
> then but were unable to nail it down completely as we're only a small
> company and restricted in resources.
>
> After the mail from Mike Perez regarding missing reports [2] i had brief
> contact with him directly via email [3] and once more on the third party
> mailing list [4].
>
> As i did not receive a message after the replies i did not expect there to
> be a defined deadline and I did not see information about the impending
> revert on gerrit, and thus was unable to comment on that.
>
> My apologies for that.
>
> We're focusing on this with all the team now.
>
>
>
> Silvan Kaiser
>
>
>
>
>
> [1] https://review.openstack.org/#/c/191192/
>
> [2]
> http://lists.openstack.org/pipermail/third-party-announce/2015-June/000200.html
>
> [3]
> http://lists.openstack.org/pipermail/third-party-announce/2015-June/000213.html
>
> [4]
> http://lists.openstack.org/pipermail/third-party-announce/2015-June/000214.html
>
>
>
>
>
> 2015-07-03 16:31 GMT+02:00 Silvan Kaiser :
>
>  Hello!
>
> I just found the following commit in the cinder log:
>
>
>
> commit a3f4eed52efce50c2eb1176725bc578272949d7b
>
> Merge: 6939b4a e896ae2
>
> Author: Jenkins 
>
> Date:   Thu Jul 2 23:14:39 2015 +
>
>
>
> Merge "Revert First version of Cinder driver for Quobyte"
>
>
>
>
>
> Is this part of some restructuring work, etc. that i did miss?
>
> I could not find a gerrit review for this and had no prior information? I
> did not see any related information when i did my weekly checks of the
> cinder weekly meeting logs and am confused to find this commit.
>
>
>
> We're still working on the CI issues discussed on the CI mailing list and
> am fully aware that we've to get this stably reporting. This is not a
> removal because of the CI issues?
>
> Best regards
>
> Silvan Kaiser
>
>
>
>
>
> --
>
> Dr. Silvan Kaiser
>
> Quobyte GmbH
> Boyenstr. 41 - 10115 Berlin-Mitte - Germany
> +49-30-814 591 800 - www.quobyte.com
> Amtsgericht Berlin-Charlottenburg, HRB 149012B
> Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
>
>
>
>
>
> --
>
> Dr. Silvan Kaiser
>
> Quobyte GmbH
> Boyenstr. 41 - 10115 Berlin-Mitte - Germany
> +49-30-814 591 800 - www.quobyte.com
> Amtsgericht Berlin-Charlottenburg, HRB 149012B
> Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
>
>
>
>
> --
>
> *Quobyte* GmbH
> Hardenbergplatz 2 - 10623 Berlin - Germany
> +49-30-814 591 800 - www.quobyte.com
>
> Amtsgericht Berlin-Charlottenburg, HRB 149012B
> management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dr. Silvan Kaiser
Quobyte GmbH
Boyenstr. 41 - 10115 Berlin-Mitte - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender

-- 

--
*Quobyte* GmbH
Hardenbergplatz 2 - 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] FFE Request: Re-add Quobyte Cinder Driver

[Silvan Kaiser]

Hello Cinder Community!
I'd like to request a feature freeze exception for change [1], re-adding the 
Quobyte driver to Cinder.

The driver was removed in change [2] due to missing CI activity [3], it was 
originally added in the kilo release [4].
We've been able to remove the CI's issues and it has been reporting for a week 
now [5], stably testing and consistently showing two bugs (one in Nova and one 
in our driver/Cinder),
referenced on the CIs status page [6]. We're monitoring the CI results 
continuously and the detected bugs are beeing addressed.
The complete logs can be reviewed at [7].
CI status changes are published on the Quobyte CI Status page in the wiki [6], 
where there’s also our contact information.
Thanks a lot for considering and best regards
Silvan Kaiser
(kaisers/casusbelli in IRC)


[1] https://review.openstack.org/#/c/201507/
[2] https://review.openstack.org/#/c/191192/
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068609.html
[4] https://review.openstack.org/#/c/94186/
[5] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069183.html
[6] https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI
[7] http://176.9.127.22:8081/?C=M;O=D


-- 

--
*Quobyte* GmbH
Hardenbergplatz 2 - 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender

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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Daneyon Hansen (danehans)]

+1

From: "Steven Dake (stdake)" mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, July 13, 2015 at 7:40 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team.  He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation.  His statistics are fantastic including both code and 
reviews.  His reviews are not only voluminous, but consistently good.  Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote is a veto 
for the candidate, so if you are on the fence, best to abstain :)  We require 3 
core reviewer votes to approve a candidate.  I will leave the voting open until 
July 20th  UTC.  If the vote is unanimous prior to that time or a veto vote 
is received, I’ll close voting and make appropriate adjustments to the gerrit 
groups.

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

Re: [openstack-dev] [all] Setting epoch in setup.cfg??

[Monty Taylor]

On 07/14/2015 11:08 AM, Ian Cordasco wrote:
> 
> 
> On 7/13/15, 16:19, "Joshua Harlow"  wrote:
> 
>> Ian Cordasco wrote:
>>>
>>> On 7/13/15, 15:09, "Dave Walker"  wrote:
>>>
 On 13 Jul 2015 8:52 pm, "Ian Cordasco"
 wrote:
> On 7/13/15, 03:38, "Thierry Carrez"  wrote:
 
>> By "counter-productive", I meant: likely to generate more confusion
> than
>> clarity. If you provide an epoch in the version and it doesn't match
>> downstream packagers ones, it's hard to rely on it.
> I see what you mean now. The thing is that for Debian/Fedora the epoch
> syntax is different from PEP 440
>
> For them it's
>
> [distro-epoch]:[upstream-version][otherstuff]
>
> PEP 440 epochs are separated by a !, so let's say $(distro) has an
> epoch
> value of "1" and we choose "2", for glance the version would look ugly
> but
> would be:
>
> 1:2!11.0.0
>
 
 This would be a problem for at least Ubuntu and Debian as the version
 string is specifically not allowed to contain a '!'.
 "The upstream_version may contain only alphanumerics and the
 characters .
 +- : ~ (full stop, plus, hyphen, colon, tilde) and should start with a
 digit." [0]
>>>
>>> Thanks for the input Dave. I didn't see that part since I was
>>> specifically
>>> looking for how epochs are denoted. I still am quite certain that we
>>> have
>>> no choice but to use the proper versioning tools upstream though and
>>> that
>>> means using ! to indicate the epoch in our version strings because these
>>> are fundamentally Python packages.
>>
>> +1 we produce python versions, and people use them (whether they are
>> uploaded to pypi or not) so we should try to do the right thing here no
>> matter what. If downstream distro (rh, ubuntu, other...) wants to
>> convert that into its local epoch scheme that's cool (and I would expect
>> them to do that in the correct manner that is appropriate for there
>> packages).
> 
> Since the mailing list reaches the largest number of people, I thought I'd
> continue some of this discussion here.
> 
> Yesterday some further discussion happened in #openstack-infra (on IRC),
> and the crux of the argument against Epochs seems to be that they make it
> hard to deal with archives on the command line, e.g., you'd have an
> archive generated that looks like:
> 
> nova-1!12.0.0.tar.gz
> 
> Perhaps I'm misunderstanding, but any relatively modern shell that allows
> for tab completion will properly tab-complete that when using the filename.
> 
> Another argument is that this is something ugly that we'll have to live
> with for the rest of OpenStack's life. Without it, however, we'll have to
> live with 12.0.0 < (the last four years of version numbers) as a sorting
> mechanism as far as Python packaging is concerned.
> 
> There's also the argument that (paraphrasing) this isn't really a problem
> for people using pip because you can do `pip install -U nova==12.0.0` once
> and you're done. Except that if you have a local package index and you're
> support reproducible builds of multiple versions, say, Juno (2014.2.x),
> Kilo (2015.1.y), Liberty (your version number depends on project but is
> strictly less than both Juno and Kilo), and M. If you upgrade a project
> from Liberty to M, you have to still use `pip install -U nova==13.0.0`
> because `pip install -U nova` will install Kilo because neither Liberty
> nor M are using an epoch. We're effectively saying "if you support more
> than one release at a time using the python packaging ecosystem, you're a
> second class citizen in OpenStack".
> 
> In other words, this will be an ongoing problem. Epochs are clearly a
> necessity, otherwise our downstream distributors wouldn't be using them
> and the PEP 440 authors wouldn't have included them. Epochs were designed
> exactly for this situation, and while they're ugly, they're the absolutely
> correct approach here.
> 
> As a sidenote, in case people are wondering how epochs even work with pip,
> 2015.1.0 has an implicit epoch of 0, e.g., the version can be equivalently
> written as 0!2015.1.0. 1!12.0.0 would sort higher because 1 has a higher
> value than the implicit 0. 1!13.0.0 then defers to the rest of the version
> string because they belong to the same epoch.

Those are all only physical manifestations of the concern I shared, not
the concerns themselves.

Here are my actual thoughts and concerns:

pip is not a downstream distribution. It is not as rich as dpkg or rpm.
The issues that they solve by using epochs are not the same problem
space pip exists in.

In downstream distros, such as debian and fedora, the work of and
complexity of epochs are packager concerns. End users are not generally
exposed to them, because a release of a Linux distro has one version of
a given thing at any time. So the problem space as a user is "I want to
install the version of the software that exists in the current release
of my distro contains" In 

Re: [openstack-dev] [all] Setting epoch in setup.cfg??

[Ian Cordasco]

On 7/13/15, 16:19, "Joshua Harlow"  wrote:

>Ian Cordasco wrote:
>>
>> On 7/13/15, 15:09, "Dave Walker"  wrote:
>>
>>> On 13 Jul 2015 8:52 pm, "Ian Cordasco"
>>>wrote:
 On 7/13/15, 03:38, "Thierry Carrez"  wrote:
>>> 
> By "counter-productive", I meant: likely to generate more confusion
 than
> clarity. If you provide an epoch in the version and it doesn't match
> downstream packagers ones, it's hard to rely on it.
 I see what you mean now. The thing is that for Debian/Fedora the epoch
 syntax is different from PEP 440

 For them it's

 [distro-epoch]:[upstream-version][otherstuff]

 PEP 440 epochs are separated by a !, so let's say $(distro) has an
epoch
 value of "1" and we choose "2", for glance the version would look ugly
 but
 would be:

 1:2!11.0.0

>>> 
>>> This would be a problem for at least Ubuntu and Debian as the version
>>> string is specifically not allowed to contain a '!'.
>>> "The upstream_version may contain only alphanumerics and the
>>>characters .
>>> +- : ~ (full stop, plus, hyphen, colon, tilde) and should start with a
>>> digit." [0]
>>
>> Thanks for the input Dave. I didn't see that part since I was
>>specifically
>> looking for how epochs are denoted. I still am quite certain that we
>>have
>> no choice but to use the proper versioning tools upstream though and
>>that
>> means using ! to indicate the epoch in our version strings because these
>> are fundamentally Python packages.
>
>+1 we produce python versions, and people use them (whether they are
>uploaded to pypi or not) so we should try to do the right thing here no
>matter what. If downstream distro (rh, ubuntu, other...) wants to
>convert that into its local epoch scheme that's cool (and I would expect
>them to do that in the correct manner that is appropriate for there
>packages).

Since the mailing list reaches the largest number of people, I thought I'd
continue some of this discussion here.

Yesterday some further discussion happened in #openstack-infra (on IRC),
and the crux of the argument against Epochs seems to be that they make it
hard to deal with archives on the command line, e.g., you'd have an
archive generated that looks like:

nova-1!12.0.0.tar.gz

Perhaps I'm misunderstanding, but any relatively modern shell that allows
for tab completion will properly tab-complete that when using the filename.

Another argument is that this is something ugly that we'll have to live
with for the rest of OpenStack's life. Without it, however, we'll have to
live with 12.0.0 < (the last four years of version numbers) as a sorting
mechanism as far as Python packaging is concerned.

There's also the argument that (paraphrasing) this isn't really a problem
for people using pip because you can do `pip install -U nova==12.0.0` once
and you're done. Except that if you have a local package index and you're
support reproducible builds of multiple versions, say, Juno (2014.2.x),
Kilo (2015.1.y), Liberty (your version number depends on project but is
strictly less than both Juno and Kilo), and M. If you upgrade a project
from Liberty to M, you have to still use `pip install -U nova==13.0.0`
because `pip install -U nova` will install Kilo because neither Liberty
nor M are using an epoch. We're effectively saying "if you support more
than one release at a time using the python packaging ecosystem, you're a
second class citizen in OpenStack".

In other words, this will be an ongoing problem. Epochs are clearly a
necessity, otherwise our downstream distributors wouldn't be using them
and the PEP 440 authors wouldn't have included them. Epochs were designed
exactly for this situation, and while they're ugly, they're the absolutely
correct approach here.

As a sidenote, in case people are wondering how epochs even work with pip,
2015.1.0 has an implicit epoch of 0, e.g., the version can be equivalently
written as 0!2015.1.0. 1!12.0.0 would sort higher because 1 has a higher
value than the implicit 0. 1!13.0.0 then defers to the rest of the version
string because they belong to the same epoch.

Cheers,
Ian


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

[openstack-dev] [requirements][all] policy on approving constraint changes

[Doug Hellmann]

At one point Robert proposed that we change the policy for approving
constraint changes like https://review.openstack.org/#/c/201408/ to
allow a single reviewer to approve it, assuming the tests were green.
Is that our current policy, or are we waiting for the integration of
constraints with our tox environments before deciding whether to make
that change?

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] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2015-07-14 13:08:46 +:
> On 2015-07-14 08:38:57 -0400 (-0400), Sean Dague wrote:
> > There is trove classification in the projects themselves right?
> [...]
> > That seems like it should be enough information to know the 2.6 question.
> 
> I got to thinking through what this might look like, and while
> filtering down the markers based on versions stated in trove
> classifiers is fairly trivial when it's just a single == or != (such
> as your example), we would also want to take into account inequality
> operators for version ranges and logical constructions (and, or,
> parenthetical ordering) which suggest that any marker simplification
> routine is probably better implemented in setuptools/pkg_resources
> which is already parsing these.

I did some work to find the supported versions in
https://review.openstack.org/#/c/181165/4/inc/python,cm as part of the
changes to devstack to support python 3.

Doug

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

[openstack-dev] Hyper-V Meeting

[Peter Pouliot]

Hi All,

We still have a lack of quorum today do to summer holidays, so we're postponing 
until everyone is back.

p

Peter J. Pouliot CISSP
Microsoft Enterprise Cloud Solutions
C:\OpenStack
New England Research & Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E: ppoul...@microsoft.com

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

[openstack-dev] [docs] [tc] Project and service names

[Anne Gentle]

Hi all,
Renamed the thread to get some topics in the subject, and I wanted to bring
this review to everyone's attention.

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

I will reconsider these guidelines based on feedback. That said, I have
done the legwork to ask about legal guidance and I still believe that
lowercase nearly always is best to reduce cognitive burden.

Thanks,
Anne

On Tue, Jul 7, 2015 at 9:36 PM, Anne Gentle 
wrote:

>
>
>>
>>  Forwarded Message 
>> Subject:[openstack-dev] Should project name be uppercase or
>> lowercase?
>> Date:   Tue, 7 Jul 2015 18:21:57 +0900
>> From:   Yuiko Takada 
>> Reply-To:   OpenStack Development Mailing List (not for usage
>> questions)
>> 
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>>
>>
>>
>> Hi folks,
>>
>> I found the difference between wiki[1] and governance[2].
>>
>
> Yes, we are aware of the differences. I have asked the OpenStack
> Foundation legal counsel and they do not have a legal reason to capitalize
> project names.
>
> So, in documentation for consistency and to work on more valuable efforts,
> we need to stick to the established Documentation Conventions that have
> been in place since October 2013.
>
>
> https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names
>
>
>
>> wiki says "Generally the capitalization of the project team names like
>> swift is lowercase."
>> But in governance, written as uppercase like "Nova", "Swift".
>>
>
> I don't believe a machine-readable YAML file indicates style or
> conventions for capitalization for a collection.
>
> Yes, I will be doing a patch for service names since it is a source of
> reference and if we think it will alleviate confusion I'll also lowercase
> the names of the projects in a separate patch.
>
>
>> How do you think which should we use uppercase vs lowercase for
>> representing project names?
>>
>
> I'll be patching the governance repo with some guidelines we have been
> using to make them official. The projects.yaml file is the reference point
> for the service catalog and documentation, and the doc team maintains a
> lookup list on the wiki page referenced above.
>
> Conventions for service names:
>
>- Uppercase first letter of first word only.
>- Do not use OpenStack in the name of the service.
>- Use module if it is consuming other services (such as heat).
>- Use service in general as that is mostly what is being added as
>projects.
>
> Conventions for project names:
>
>- In documentation published to docs.openstack.org, use lower case for
>project names except at the beginning of a sentence or heading title.
>(Note that all heading titles use sentence case for ease of learning
>capitalization rules.)
>- In the service catalog, use lower case.
>
> I hope this clarification helps. Please let me know if you have any
> questions or concerns.
>

Hi again all,
I have


>
> Thanks,
> Anne
>
>
>
>>
>>
>> [1]https://wiki.openstack.org/wiki/Documentation/Conventions
>> [2]
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>>
>>
>> Best Regards,
>> Yuiko Takada
>>
>>
>>
>> --
>> Christian Berendt
>> Cloud Solution Architect
>> Tel.: +49-171-5542175
>> Mail: bere...@b1-systems.de
>>
>> B1 Systems GmbH
>> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
>> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>>
>
>
>
> --
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.com
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Adding results to extension callbacks (ml2 port_update ext handling).

[Robert Kukura]

I haven't had a chance to review this patch in detail yet, but am 
wondering if this is being integrated with ML2 as an extension driver? 
If so, that should clearly address how dictionaries are extended and 
input values are validated. If not, why?


-Bob

On 7/13/15 10:50 PM, Miguel Angel Ajo wrote:

Inline reply (I've added to CC relevant people for ml2/plugin.py
port_update extension
handing -via git blame-) as they probably have an opinion here
(specially the last
two options).

Kevin Benton wrote:

This sounds like a lot of overlap with the dict extend functions. Why
weren't they adequate for the QoS use case?


Let me explain, I believe Mike exceeded the proposal with AFTER_READ,
that's not the plan,
even if we could do as he proposed,

AFTER_READ dict extension is just a temporary workaround until we have
a separate explicit
api @armax is working on. Making explicit that your service is going
to extend resources,
and handled that in an ordered way is a good thing.

Afterwards, the source of this review has came from ML2 implementation of
AFTER_CREATE/AFTER_UPDATE notification for ports/nets.

Let me explain:

 As a decoupled, "mixinless" service extending core resources, we
need to do two things:

1) Extending the core resources as other extensions would do, adding
stuff to the port/network
dicts, here's where it comes the current AFTER_READ dict extension,
and future API making
that more explicit and more controlled.

2) Verifying the extended values we receive on core resources, by
registering to BEFORE_*
callbacks. For example, if a tenant is trying to use a qos_profile_id
he doesn't have access to,
or that doesn't exist, we can cancel the operation by throwing an
exception.

  We need to extend the notifications for ports and networks, as
that's not notified currently.
Mike will work on that too in a separate patch.


3) Taking the finally extended values and store associations in database
 (AFTER_UPDATE/AFTER_CREATE) so any later reads of the
port/network will get the right
 qos_profile_later in "after read".


We have found that AFTER_CREATE/AFTER_UPDATE happens at plugin level
(neutron/plugins/ml2/plugin.py / update_port) and that information
passed down is
very brief to our case (basically a "None" port if no ml2-know
attribute is changed), and
ml2 has to be aware of every single extension.

Here there are two options:
   a) we make ml2 also aware of qos_profile_id changes, complicating
the business logic down
there, or...

   b) we send the AFTER_CREATE/UPDATE events, and we listen to the
callback
listeners to such notification, and they will tell us if there's any
relevant field which must
be propagated down to agents. Then it's up to the agents to use such
field or not.


   Mike's patch proposal is in the direction of (b), he's a long term
thinker, I was proposing him
to just go (a) for now, but let's discuss and find what's more right.



On Mon, Jul 13, 2015 at 7:58 AM, Mike Kolesnik
wrote:


Hi,

I sent a simple patch to check the possibility to add results to
callbacks:
https://review.openstack.org/#/c/201127/

This will allow us to decouple the callback logic from the ML2
plugin in
the QoS scenario where we need to update the agents in case the
profile_id
on a port/network changes.
It will also allow for a cleaner way to extend resource attributes as
AFTER_READ callbacks can return a dict of fields to add to the original
resource instead of mutating it directly.

Please let me know what you think of this idea.

Regards,
Mike


__

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





__

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





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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Jeff Peeler]

On Tue, Jul 14, 2015 at 01:56:16PM +0200, Harm Weites wrote:


no-brainer: +1

Op 14-07-15 om 13:19 schreef Ryan Hallisey:

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team. He did a fantastic 
job getting Kolla into shape to support multiple distros and from 
source/from binary installation. His statistics are fantastic 
including both code and reviews. His reviews are not only voluminous, 
but consistently good. Paul is helping on many fronts and I would feel 
make a fantastic addition to our core reviewer team.


Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a 
veto for the candidate, so if you are on the fence, best to abstain :) 
We require 3 core reviewer votes to approve a candidate. I will leave 
the voting open until July 20th  UTC. If the vote is unanimous 
prior to that time or a veto vote is received, I’ll close voting and 
make appropriate adjustments to the gerrit groups.


+1!

__
OpenStack Development Mailing List (not 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] [Murano] Versioning of Murano packages and MuranoPL classes

[Kirill Zaitsev]

Alexander, do you plan to update the https://review.openstack.org/#/c/140402/ 
versioning spec? We can possibly try to make it a joint effort, if you like.


-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 14 Jul 2015 at 11:34:56, Alexander Tivelkov (ativel...@mirantis.com) wrote:

Gosha,

Could you please elaborate what do you mean by extra blocks? Glance V3 comes 
with Glance out-of-the box, no extra deployment is needed. The only thing one 
will have to install is Murano Package Type plugin - but it will be installed 
at the same time with Murano.

--
Regards,
Alexander Tivelkov

On Mon, Jul 13, 2015 at 5:54 PM, Georgy Okrokvertskhov 
 wrote:


On Mon, Jul 13, 2015 at 2:19 AM, Alexander Tivelkov  
wrote:
Hi Gosha,

Supporting versioning in existing backend will require us to re-implement the 
significant part of Artifact Repository in Murano API: we'll need to add 
versions and dependencies concepts into our model (which is already complicated 
and dirty enough), extend appropriate API calls etc. And all the efforts will 
be a waste of time once we finally migrate to Artifacts.

Also, what do you mean by "set by default"? V3 API is experimental, but it is 
already merged into upstream Glance, so there is no problem with using it in 
Murano right away.

This is exactly why I have these concerns. I wonder how much customers will use 
experimental API in production. I just don't want to add extra block on Murano 
adoption way.

 
--
Regards,
Alexander Tivelkov

On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov 
 wrote:
Hi Alex,

Thank you for the great summary.

I have a concern about item #8. Can we add an option to Murano to use previous 
storage engine rather then Glance v3? We need to make sure that v3 API in 
Glance is set by default before we do a hard dependency on it in Murano.

Thanks
Gosha

On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov  
wrote:
Hi folks,

Ability to manage multiple versions of application packages and their 
dependencies was always an important item in Murano roadmap, however we still 
don't have a clear spec for this feature. 
Yesterday we hosted a small design session to come up with a plan on what can 
be done in Liberty timeframe to have proper versioning for MuranoPL classes and 
packages. Stan Lagun, Kirill Zaitsev and myself participated offline, some 
other muranoers joined remotely. Thanks to everybody who joined us.

TL;DR: it turns out that now we have a clear plan which will allow us to 
achieve proper versioning of the packages and classes, and we'll try to 
implement the most important parts of it in Liberty.

Here is the detailed outcome of the session:

We'll use the standard Semantic Versioning format 
('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our 
packages: changes which break backwards-compatibility should increment the 
major segment, non-breaking new features increment the minor segment and all 
non-breaking bugfixes increment the patch segment. The developers should be 
carefull with the "new features" part: if you add a new method to a class, it 
may be considered a breaking change if the existing subclasses of this class 
have the same method already declared. We still assume that such changes should 
lead to increment of 'minor' segment, however it is up to best judgement of 
developers in particular case: if the risk of such method override is really 
high it may worth to increment the 'major' segment. Proper guideline on the 
versioning rules will be published closer to L release.

A new field 'Version' is introduced into package manifest file which should 
define package version in complete semver format. The field itself is optional 
(so existing apps are not broken), if it is not specified the package is 
assumed to have version '0.0.0'

The existing 'Require' block of Application manifest will be used to specify 
the package dependencies. Currently it is a yaml-based dictionary, with the 
keys set to fully-qualified names of the dependency packages and the values set 
to the version of those dependencies. Currently this block is used only for 
integration with apps stored at apps.openstack.org. It is suggested to use this 
block in the deployment process as well, and extend its semantics.
The version of the dependency specified there should also follow the semver 
notation, however it may be specified in the shortened format, i.e. without 
specifying the 'patch' or 'patch' and 'minior' components. In this case the 
dependency will be specified as a range of allowed versions. For example, a 
dependency version 1.2 will mean a (1.2.0 >= version < 1.3) range.
If the version of a dependency is not specified (like in this existing app - 
[1]) then we assume the version "0" - i.e. the last available pre-release 
version of a package.

Murano core library is also a package which has its own version. The current 
one is assumed to have a version 0.1.0, the one which is going to be released 
in L will b

Re: [openstack-dev] Cinder as generic volume manager

[Jan Safranek]

On 07/10/2015 12:19 AM, Walter A. Boring IV wrote:
> On 07/09/2015 12:21 PM, Tomoki Sekiyama wrote:
>> Hi all,
>>
>> Just FYI, here is a sample script I'm using for testing os-brick which
>> attaches/detaches the cinder volume to the host using cinderclient and
>> os-brick:
>>
>> https://gist.github.com/tsekiyama/ee56cc0a953368a179f9
>>
>> "python attach.py " will attach the volume to the executed
>> host and shows a volume path. When you hit the enter key, the volume is
>> detached.
>>
>> Note this is skipping "reserve" or "start_detaching" APIs so the volume
>> state is not changed to "Attaching" or "Detaching".
>>
>> Regards,
>> Tomoki
> 
> Very cool Tomoki.  After chatting with folks in the Cinder IRC channel
> it looks like we are going to look at going with something more like what
> your script is doing.   We are most likely going to create a separate
> command line tool that does this same orchestration, using cinder client, a 
> new
> Cinder API that John Griffith is working on, and os-brick.

Very cool indeed, it looks exactly like as what I need.


Jan


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

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Jeremy Stanley]

On 2015-07-14 08:38:57 -0400 (-0400), Sean Dague wrote:
> There is trove classification in the projects themselves right?
[...]
> That seems like it should be enough information to know the 2.6 question.

I got to thinking through what this might look like, and while
filtering down the markers based on versions stated in trove
classifiers is fairly trivial when it's just a single == or != (such
as your example), we would also want to take into account inequality
operators for version ranges and logical constructions (and, or,
parenthetical ordering) which suggest that any marker simplification
routine is probably better implemented in setuptools/pkg_resources
which is already parsing these.
-- 
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] [Fuel] Separate repo for Fuel Agent

[Vladimir Kozhukalov]

Dear colleagues,

New repository [1] has been created. So, please port all your review
requests to stackforge/fuel-web related to Fuel Agent to this new
repository. Currently, I am testing these two patches
https://review.openstack.org/#/c/200595
https://review.openstack.org/#/c/200025. If they work, we need to merge
them and that is it. Review is welcome.



[1] https://github.com/stackforge/fuel-agent.git

Vladimir Kozhukalov

On Fri, Jul 10, 2015 at 8:14 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Ok, guys.
>
> Looks like there are no any objections. At the moment I need to create
> actual version of upstream repository which is going to be sucked in by
> OpenStack Infra. Please, be informed that all patches changing
> fuel-web/fuel_agent that will be merged after this moment will need to be
> ported into the new fuel-agent repository.
>
>
> Vladimir Kozhukalov
>
> On Fri, Jul 10, 2015 at 6:38 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Guys, we are next to moving fuel_agent directory into a separate
>> repository. Action flow is going to be as follows:
>>
>> 1) Create verify jobs on our CI https://review.fuel-infra.org/#/c/9186
>> (DONE)
>> 2) Freeze fuel_agent directory in https://github.com/stackforge/fuel-web
>> (will announce in a separate mail thread). That means we stop merging
>> patches into master which change fuel_agent directory. Unfortunately, all
>> review requests need to be re-sent, but it is not going to be very
>> difficult.
>> 3) Create temporary upstream repository with fuel_agent/* as a content.
>> I'm not planning to move 5.x and 6.x branches. Only master. So, all fixes
>> for 5.x and 6.x will be living in fuel-web.
>> 4) This upstream repository is going to be sucked in by openstack-infra.
>> Patch is here https://review.openstack.org/#/c/199178/ (review is
>> welcome) I don't know how long it is going to take. Will try to poke infra
>> people to do this today.
>> 5) Then we need to accept two patches into new fuel-agent repository:
>>  - rpm spec (extraction from fuel-web/specs/nailgun.spec) (ready, but
>> there is no review request)
>>  - run_tests.sh (to run tests) (ready, but there is no review request)
>>
>> !!! By this moment there won't be any impact on ISO build process !!!
>>
>> 6) Then we need to change two things at the same time (review is welcome)
>>   - fuel-web/specs/nailgun.spec in order to prevent fuel-agent package
>> building  https://review.openstack.org/#/c/200595
>>   - fuel-main so as to introduce new fuel-agent repository into the build
>> process https://review.openstack.org/#/c/200025
>>
>> And good luck to me -)
>>
>>
>> Vladimir Kozhukalov
>>
>> On Wed, Jul 8, 2015 at 12:53 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> There were some questions from Alexandra Fedorova about independent
>>> release cycle.
>>>
>>> >according to the configuration [1] Infra team won't be able to do
>>> >branching or any kind of release management for new repository.
>>>
>>> >Could you please clarify, do we plan to version new repository the
>>> >same way as we do for main fuel repositories or there going to be
>>> >separate releases as in python-fuelclient [2]? Who should drive the
>>> >release process for this repo and how this change will affect Fuel ISO
>>> >release?
>>>
>>> >[1]
>>> https://review.openstack.org/#/c/199178/1/gerrit/acls/stackforge/fuel-agent.config,cm
>>> >[2]
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-July/068837.html
>>>
>>> IMO all Fuel components should be as much independent as possible with
>>> highly defined APIs used for their interaction, with their own teams, with
>>> their own independent release cycles. But we cannot switch to this model
>>> immediately. For the start, we can just move those components into separate
>>> repositories, leaving the same access rights and core team as we have for
>>> fuel-web.
>>>
>>> When Fuel Agent is a separate repository we discuss team. It looks like
>>> a team leader is the best person to manage releases for a particular
>>> component. This thread is totally about separation stuff and how to do this
>>> not breaking anything.
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Wed, Jul 8, 2015 at 12:24 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 Dear colleagues,

 I am going to move Fuel Agent into a separate git repository. The thing
 is that we have quite a few review requests to fuel-web with changes for
 Fuel Agent. The new repository is going to look like this
 https://github.com/kozhukalov/fuel-agent i.e. there is no additional
 sub-directory fuel_agent. In fact, I don't think it is a big deal to update
 all fuel agent related review requests.

 Work items:
 0) request to openstack-infra https://review.openstack.org/#/c/199178/1
 0.1) upstream for this request with commit history
 https://github.com/kozhukalov/fuel-agent
 1) fuel-agent/specs/fuel-ag

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Jeremy Stanley]

On 2015-07-14 08:38:57 -0400 (-0400), Sean Dague wrote:
> There is trove classification in the projects themselves right?
[...]
> That seems like it should be enough information to know the 2.6 question.

Only if it's kept up to date. If we're going to rely on it (not a
terrible idea) then we should enforce it in tests somewhere first.
-- 
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] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Sean Dague]

On 07/14/2015 08:11 AM, Andrey Kurilin wrote:
> Hi!
> It looks like novaclient still supports py26 :) At least, there is a
> gate-python-novaclient-python26 job.
> Also, I checked several commands(boot, *list, delete ) with python 2.6
> env and they work as expected for me.

Ah, right fair, my bad. I had thought we'd adjusted that with all the
branching.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Sean Dague]

On 07/14/2015 08:32 AM, Jeremy Stanley wrote:
> On 2015-07-14 07:03:34 -0400 (-0400), Sean Dague wrote:
>> I just saw this Nova review come in -
>> https://review.openstack.org/#/c/200908
>>
>> Why are we merging 2.6 requirements for projects that don't support 2.6?
>> That seems potentially confusing to end users that now think the project
>> does, because there are still references in the code.
> 
> We could likely consider treating 2.6+2.7-supporting vs 2.7-only
> (and 2.7+3.4-supporting? and 2.6+2.7+3.4?) repos differently where
> requirements sync and enforcement are concerned, but a first step
> for that would involve coming up with and maintaining a list of
> which repos have support on which branches for which Python
> versions. We don't have such a thing today as far as I'm aware, as
> it's merely an emergent property based on a combination of factors
> in zuul's layout file (the names of 2.6-based jobs, which repos run
> them, and the branches on which they're allowed to run).

There is trove classification in the projects themselves right?

[metadata]
name = nova
version = 12.0.0
summary = Cloud computing fabric controller
description-file =
README.rst
author = OpenStack
author-email = openstack-dev@lists.openstack.org
home-page = http://www.openstack.org/
classifier =
Environment :: OpenStack
Intended Audience :: Information Technology
Intended Audience :: System Administrators
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux
Programming Language :: Python
Programming Language :: Python :: 2
Programming Language :: Python :: 2.7


That seems like it should be enough information to know the 2.6 question.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Jeremy Stanley]

On 2015-07-14 07:03:34 -0400 (-0400), Sean Dague wrote:
> I just saw this Nova review come in -
> https://review.openstack.org/#/c/200908
> 
> Why are we merging 2.6 requirements for projects that don't support 2.6?
> That seems potentially confusing to end users that now think the project
> does, because there are still references in the code.

We could likely consider treating 2.6+2.7-supporting vs 2.7-only
(and 2.7+3.4-supporting? and 2.6+2.7+3.4?) repos differently where
requirements sync and enforcement are concerned, but a first step
for that would involve coming up with and maintaining a list of
which repos have support on which branches for which Python
versions. We don't have such a thing today as far as I'm aware, as
it's merely an emergent property based on a combination of factors
in zuul's layout file (the names of 2.6-based jobs, which repos run
them, and the branches on which they're allowed to run).
-- 
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] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Andrey Kurilin]

Hi!
It looks like novaclient still supports py26 :) At least, there is a
gate-python-novaclient-python26 job.
Also, I checked several commands(boot, *list, delete ) with python 2.6 env
and they work as expected for me.

On Tue, Jul 14, 2015 at 2:03 PM, Sean Dague  wrote:

> I just saw this Nova review come in -
> https://review.openstack.org/#/c/200908
>
> Why are we merging 2.6 requirements for projects that don't support 2.6?
> That seems potentially confusing to end users that now think the project
> does, because there are still references in the code.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Harm Weites]

no-brainer: +1

Op 14-07-15 om 13:19 schreef Ryan Hallisey:

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks,

I am proposing Paul Bourke for the Kolla core team. He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation. His statistics are fantastic including both code and 
reviews. His reviews are not only voluminous, but consistently good. Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for 
the candidate, so if you are on the fence, best to abstain :) We require 3 core 
reviewer votes to approve a candidate. I will leave the voting open until July 
20th  UTC. If the vote is unanimous prior to that time or a veto vote is 
received, I’ll close voting and make appropriate adjustments to the gerrit 
groups.

Regards
-steve

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

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



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

Re: [openstack-dev] [neutron][security-group] rules for filter mac-addresses

[yan_xing...@163.com]

Thank you, Kevin. 
I search the blueprint about this point in launchpad.net, and got nothing, then 
register one at:
https://blueprints.launchpad.net/neutron/+spec/security-group-mac-rule 




Yan Xing'an
 
From: Kevin Benton
Date: 2015-07-14 18:31
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][security-group] rules for filter 
mac-addresses
Unfortunately the security groups API does not have mac-level rules right now.

On Tue, Jul 14, 2015 at 2:17 AM, yan_xing...@163.com  
wrote:
Hi, all:

Here is a requirement: deny/permit incoming packets on VM by mac addresses,
I have tried to find better method than modifying neutron code, but failed.
Any suggesion is grateful. Thank you.

Yan.



yan_xing...@163.com

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




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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Ryan Hallisey]

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

Hey folks, 

I am proposing Paul Bourke for the Kolla core team. He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation. His statistics are fantastic including both code and 
reviews. His reviews are not only voluminous, but consistently good. Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team. 

Consider my proposal to count as one +1 vote. 

Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for 
the candidate, so if you are on the fence, best to abstain :) We require 3 core 
reviewer votes to approve a candidate. I will leave the voting open until July 
20th  UTC. If the vote is unanimous prior to that time or a veto vote is 
received, I’ll close voting and make appropriate adjustments to the gerrit 
groups. 

Regards 
-steve 

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

__
OpenStack Development Mailing List (not 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][heat][oslo] Public show and validation clients methods

[Sergey Kraynev]

Doug, Terry.

Thank you for the feedback.
I will create a BP with list of desired public methods and will add all
projects to it.

Regards,
Sergey.

On 9 July 2015 at 21:20, Doug Hellmann  wrote:

> Excerpts from Sergey Kraynev's message of 2015-07-09 18:26:09 +0300:
> > Hi community.
> >
> > I want to raise couple questions about openstack clients.
> > In Heat we use other python-*clients for manipulating service's
> resources,
> > but some stuff placed in shell.py modules and we are forced to duplicate
> > some existing code.
> >
> > There are couple examples which I met last time:
> >  - getting resource by name or id
> >
> > All clients implement this logic in the shell.py module and it's not
> > possible to re-use it from client
> > directly as single call of some function "resolve_by_name_or_id"
> > (unfortunately same is for Heat too ). As result all external developers
> > (and we too as orchestration tool) should copy logic in our repos and
> > implement similar resolve methods for all services/resources.
> >
> > - show command for clients
> >
> > some of clients use base Resource class and they have "._info" attribute,
> > but it's private and use it is not right too. But I did not see another
> > solution, because clients have not some *_show public method for it too
> > (except neutron :) ). Also there is additional issue, when clients use
> > their own classes, without this attribute, e.g. glance v2.
> >
> > So my question: can we create mentioned above public methods for such
> stuff
> > and make it as standard for all clients or may be discuss list of common
> > public "interfaces" for all clients?
>
> Until the SDK is ready for use, adding public methods or attributes
> seems like the best approach.
>
> Doug
>
> >
> > If it was raised early please point me, because this issue is really
> > painful, when you try to implement
> > common approach for all projects.
> >
> > Regards,
> > Sergey.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [requirements] why merging 2.6 requirements for non 2.6 supporting projects

[Sean Dague]

I just saw this Nova review come in -
https://review.openstack.org/#/c/200908

Why are we merging 2.6 requirements for projects that don't support 2.6?
That seems potentially confusing to end users that now think the project
does, because there are still references in the code.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [nova] Switching the bug status of ~200 bugs at once; Problem?

[Markus Zoeller]

Markus Zoeller/Germany/IBM@IBMDE wrote on 07/10/2015 03:55
> [...]
> > 
> > So you have a bunch of bugs that are Confirmed (or Triaged) + an
> > assignee set. I would argue that you need to separate two cases:
> > 
> > the bug had no activity for the last 60 days: assignee should be 
removed
> > 
> > the bug had activity in the last 60 days: status should be "in 
progress"
> > 
> > otherwise you further hide the fact that the bug is abandoned by 
setting
> > status in addition to the assignee.
> > 
> > Cheers,
> > 
> > -- 
> > Thierry Carrez (ttx)
> 
> Right. My first intention was to switch all to "in progress" and then
> switch a subset of that back to the previous status, depending on their
> activity. I see now that this would cause confusion. 
> I'll process them seperately like Thierry suggested to avoid that
> confusion. I'll announce the expected changes in the next days before
> I actually execute them.
> 
> Regards,
> Markus Zoeller (markus_z)

Here are the numbers. From the currently 215 "Confirmed" and "Triaged"
bugs which have an assignee (= inconsistency), there are:

 active  inactive
-
Triaged   4 5
Confirmed57   149

"active" = there is a comment within the last 60 days in Launchpad
  - or -
   the bug mentions at least one patch set in gerrit which is 
   * under review
   * verified by Jenkins
   * and without negative code reviews (older than 28 days)

"inactive" = the last update of the bug is older than 60 days
 - and -
 the bug mentions no active patch sets or only patch sets 
 which have -1s which are not addressed for 28 days.

I'm not sure why the number of the inactive confirmed bugs is so big.
Could it be that this is a way to "bookmark" bugs where one wants to
work on in the future?

Below are the details of the "Confirmed" and "Triaged" bugs which would
be affected as soon as I run the mentioned script in 'active' mode.

Maybe a short note why I think that this could improve Nova: I assume
that the average turnaround time of the bugs, from their creation until
they get closed with appropriate patch sets, can be decreased if the
'stale' bugs get a regular cleanup to enable other contributers to work
on them.

I'll wait a week until I execute this to give you some time to speak up.


Details:


Legend:
---
"=>In Progress": Switch the status of the bug to "In Progress"
"-Assignee": Remove the current assignee
"Age"  : Days since the last update (in LP or Gerrit)
"Patch Set ...": A summary of a patch set in Gerrit. Constructed as:
[review-id] (+2s +1s -1s -2s) 
(G:Jenkins Vote W:Workflow Flag) 
 
===
CleanUpReport(9 Items): 'Triaged' bugs with an assignee
===
Bug ID  Title  Age Contributer  Cleanup Action 
 
---
1467409 HyperV destroy vm fails on Wi[...]  21 Adelina Tuve =>In Progress  
 
1177570 Hyper-V tests can be refactor[...] 368 Alessandro P -Assignee  
1355171 Can not have IPv4 or IPv6 onl[...]  91 Chris Gacsal -Assignee  
1412480 Hyper-V: Instance booted from[...] 175 Claudiu Belu -Assignee  
1458013 ec2 code uses requests to tal[...]  29 Deepti Ramak =>In Progress  
 
1436079 There is no API samples funct[...] 103 Eli Qiao -Assignee  
1458934 Ironic: heavy polling   25 Lucas Alvare =>In Progress  
 
1441361 Don't trace on InstanceInfoCa[...]  96 Matt Riedema -Assignee  
1415087 [OSSA 2015-011] Format-guessi[...]   7 Tony Breeds  =>In Progress  
 
---
4 x =>In Progress
5 x -Assignee
===


===
CleanUpReport(206 Items): 'Confirmed' bugs with an assignee
===
Bug ID  Title  Age Contributer  Cleanup Action 
 
---
1309184 nova should delete neutron po[...] 305 Aaron Rosen  -Assignee  
1265447 floating-ip-bulk-delete metho[...] 151 Abhishek Tal -Assignee  
1301368 Hyper-V configdrive is not at[...] 105 Adrian Vladu -Assignee  
1335784 remove secgroup rule won't cu[...] 305 Akash Gangil -Assignee  
1153842 nova volume-attach  In Progress  
 
1301532 Quotas can be exceeded by mak[...]  90 Alex Xu  -Assignee  
Patch Set: [110863] (2 1 0 0) (G:0 W:None) age(d):341 - MERGED
1443494 Return supported micro-versio[...]  69 Alex Xu  -Assignee  
1253571 libivrt+xen does not support [...] 334 Alvaro 

[openstack-dev] [nova] Reminder: July 16 is non-priority feature proposal freeze

[John Garbutt]

Hi,

Please note, the non-priority feature freeze is on: July 30

Blueprint assignees (as always, but especially now), please update
your blueprint to:
* NeedsCodeReview, once all your code ready for review
* Implemented, once all your code has merged
Not doing this, will force me to guess randomly, which is unlikely to go well.

This proposal freeze is designed to optimise the number of completed
blueprints by the above freeze date. This freeze is to ensure the
priority items for Liberty get the attention they need. For more
details, please see:
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Non-priority_Blueprint_Feature_Freeze
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Why_is_there_a_non-priority_Feature_Freeze_in_Nova.3F

I am expecting zero proposal freeze exceptions at this point, given
the amount of really useful features that are already up for review.
Please contact me directly, ideally on IRC, if you need an exception.

Many thanks,
John

PS
There are some good proposals being drawn up for an alternative
process to the non-priority feature proposal freeze:
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Runways
We will discuss these ideas, and more, during the midcycle, in the
hope we can get some agreement (and work) on a new process, before the
start of the M release.

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