[openstack-dev] [vitrage] bp:static-datasource-config-format working items

[Yujun Zhang]

Hi folks.

I have just started working on the blueprint about static datasource config
format[1]. The planned working items are as following.

   1. create new datasource `static` to parse new configuration format
   2. parse old configuration format in `static` with a proxy to existing
   `static_physical` module
   3. remove `static_physical` datasource and print deprecation warning in
   `static`
   4. merge common logic with scenario template evaluator

Requesting for comments.

P.S. I chose the name `static` since it is actually not limited to physical
entities. Virtual entities can also be described in `static` file if there
is no dynamic source.

[1]:
https://blueprints.launchpad.net/vitrage/+spec/static-datasource-config-format

--
Yujun
__
OpenStack Development Mailing List (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] [storlets] IRC meeting today

[eran]

Hi,
We will skip this week's meeting due to majority of members who cannot join.
Apologies for the late notice.

Thanks,
Eran


__
OpenStack Development Mailing List (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] [karbor] Karbor weekly irc meeting

[edison xiang]

Hi guys,

Karbor today's weekly irc meeting will be held at 15:00 UTC
#openstack-meeting.
Weclome to add your agenda at [1] and welcome to join the meeting.

[1] https://wiki.openstack.org/wiki/Meetings/Karbor

Best Regards,

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

[openstack-dev] [neutron] Reviews needed in neutron-lib

[Henry Gessau]

During the meeting today I promised to provide a list of reviews in
neutron-lib that need review attention.

The following are patches that "rehome" code from neutron core into
neutron-lib and are therefore important to keep up the velocity of neutron-lib
adoption:

https://review.openstack.org/385045
https://review.openstack.org/391354
https://review.openstack.org/387612
https://review.openstack.org/396972
https://review.openstack.org/394244
https://review.openstack.org/397035
https://review.openstack.org/346554

(Also look for patches in neutron core that remove deprecations, or that adopt
code from neutron-lib.)


Finally, do not neglect the api-ref fixes/updates in neutron-lib, most of
these are very easy to review...

https://review.openstack.org/#/q/project:openstack/neutron-lib+status:open+file:%22%255Eapi-ref/.*%22


__
OpenStack Development Mailing 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] 答复: Re: [Senlin]Nominating Ruijie Yuan for Senlin core reviewer

[Yanyan Hu]

Hi, guys, thanks a lot for your vote. Now I have got +1 from all core
reviewers except Xinhui. And I have confirmed with her offline and she also
agrees with this nomination. So I think we can congratulate Ruijie Yuan to
become core reviewer of Senlin now:) I will change senlin-core group to
reflect this result. Thanks.

2016-11-14 15:35 GMT+08:00 :

>
> +1.
> It's happy to work with Ruijie. Congratulations.
>
> Best Regards,
> XueFeng Liu
>
>
>
>
>
> 发件人: Haiwei Xu 
> 收件人: "openstack-dev@lists.openstack.org"  openstack.org>,
> 日期: 2016-11-14 14:52
> 主题:Re: [openstack-dev] [Senlin]Nominating Ruijie Yuan for Senlin
>corereviewer
> --
>
>
>
> +1, welcome Ruijie.
>
> Regards,
> xuhaiwei
>
> -Original Message-
> From: Yanyan Hu [mailto:huyanya...@gmail.com ]
> Sent: Friday, November 11, 2016 3:28 PM
> To: openstack-dev
> Subject: [openstack-dev] [Senlin]Nominating Ruijie Yuan for Senlin core
> reviewer
>
> Hi Senlin core team,
>
> I'd like to nominate Ruijie Yuan(IRC name 'ruijie') for Senlin core
> reviewer.
>
>
> Ruijie started to work on Senlin since the beginning of Newton cycle and
> he has made significant contribution to Senlin project in last three months
> including the batch policy support, versioned API support and etc.. He is
> also actively interacting with the team for bug fix, blueprint discussion
> and code review. I have talked with him and he expressed strong enthusiasm
> and will to contribute to Senlin project and I believe he will make a great
> addition to the core review team.
>
>
> So please put your +1 or -1 here. Please note any -1 will be a veto for
> this nomination. I will collect the result in seven days.
>
>
> Thanks you so much!
>
> http://stackalytics.com/report/contribution/senlin-group/60
>
>
> --
>
> Best regards,
>
> Yanyan
> __
> OpenStack Development Mailing List (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
>
>


-- 
Best regards,

Yanyan
__
OpenStack Development Mailing 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] Fedora AArch64 (64-bit ARM) support in diskimage-builder

[Gregory Haynes]

On Mon, Nov 14, 2016, at 05:06 PM, dmar...@redhat.com wrote:
> On 11/14/2016 04:40 PM, Ben Nemec wrote:
> >
> >
> > On 11/11/2016 10:55 AM, dmar...@redhat.com wrote:
> >>
> >> I have been looking at using diskimage-builder on Fedora AArch64. While
> >> there is 64-bit ARM support for Ubuntu (arm64), there appear to be a few
> >> things missing for Fedora.  Is this the correct list to ask questions,
> >> and propose minor changes to diskimage-builder in support of this 
> >> effort?
> >
> > Yes.  I would suggest you tag your emails with [diskimage-builder] so 
> > the relevant people are more likely to see them.
> 
> Will do.
> 
> 
> Thank you for the feedback,
> 
> d.marlin
> 

Additionally, if youre an IRC fan, we hang out in #openstack-dib on
freenode.

Thanks,
Greg

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

Re: [openstack-dev] [Ironic] Baremetal Storage Service?

[Akira Yoshiyama]

Hi Jay,

Thank you for your comments.


2016-11-14 2:19 GMT+09:00 Jay Pipes :
> On 11/13/2016 01:52 AM, Akira Yoshiyama wrote:
>>
>> Hi Jay,
>>
>> 2016-11-13 3:12 GMT+09:00 Jay Pipes :
>>>
>>> On 11/12/2016 09:31 AM, Akira Yoshiyama wrote:


 Hi Stackers,

 In TripleO, Ironic provides physical servers for an OpenStack
 deployment but we have to configure physical storages manually, or
 with any tool, if required. It's better that an OpenStack service
 manages physical storages as same as Ironic for servers.

 IMO, there are 2 plans to manage physical storages:
>>>
>>>
>>> When you say "manage physical storage" are you referring to configuring
>>> something like Ceph or GlusterFS or even NFS on a bunch of baremetal
>>> servers?
>>
>>
>> No. "physical storages" means storage products like EMC VNX, NetApp
>> Data ONTAP, HPE Lefthand and so on.
>> Say there is a new service named X to manage them. A user, he/she will
>> be a new IaaS admin, requests many baremetal servers to Ironic and
>> some baremetal storages to X. After they are provided, he/she will
>> start to build a new OpenStack deployment with them. Nova in the new
>> one will provide VMs on the servers and Cinder will manage logical
>> volumes on the storages. X doesn't manage each logical volume but
>> pools, user accounts and network connections of the storages.
>
>
> Yeah, I personally believe that is the domain of configuration management
> systems not OpenStack HTTP API services. What you are describing is not a
> multi-tenant HTTP API service, it's an IT/storage admin automation tool.
>
> Incidentally, Ironic isn't multi-tenant either. It lives in the weird land
> in OpenStack of being an HTTP API service that isn't meant for "normal
> users" so in order to provider a cloud service (BareMetal-as-a-Service),
> Ironic *requires* Nova to provide the multi-tenancy aspects of the
> "as-a-Service" part of the software.

Hmm... so, if I built a (multi-tenant) baremetal IaaS service like SoftLayer
with OpenStack Newton release, tenant users can deploy an OpenStack
environment with cinder using SDS on it. No physical storages.


> Ironic is great, of course, but it ain't a cloud service without help from
> Nova.
>
> Best,
> -jay

BR,
Akira
__
OpenStack Development Mailing 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] ui-cookiecutter

[Shuu Mutou]

Hi Thai,

I created new blueprint[1], and added the BP to next IRC meeting agenda[2]. I 
hope the topic will be discussed in the meeting.

[1]https://blueprints.launchpad.net/horizon/+spec/ui-cookiecutter
[2]https://wiki.openstack.org/wiki/Meetings/Horizon

Best regards,
Shu Muto


> -Original Message-
> From: Thai Q Tran [mailto:tqt...@us.ibm.com]
> Sent: Tuesday, November 15, 2016 4:30 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon] ui-cookiecutter
> 
> Hi Shuu,
> 
> Sorry for the delay again, I just got back from vacation. I think your
> cookiecutter will be useful in a number of ways.
> 
> 1. We can use it to easily generate plugins for beginners
> 2. We can use it in Horizon's startdash command (have to look into this)
> for internal use
> 
> Ideally, the project should be under an OpenStack repo so horizon drivers
> can maintain it. Lets make it a point and bring it up at the horizon weekly
> meeting. We can proceed after community feedback.
> 
> 
>   - Original message -
>   From: Shuu Mutou 
>   To: "openstack-dev@lists.openstack.org"
> 
>   Cc: Haruhiko Katou 
>   Subject: [openstack-dev] [Horizon] ui-cookiecutter
>   Date: Tue, Nov 8, 2016 1:24 AM
> 
>   Hi Horizoners,
> 
>   Thanks for picking up ui-cookiecutter[1] and setting Ocata-2
> milestone at summit[2].
>   Thai or Cindy? Thank you!!
> 
>   I'm maintaining ui-cookiecutter, but I'm ready for transferring
> it as Horizon subproject.
> 
>   Can I start to create subproject for ui-cookiecutter?
>   Or please let me know what I should do.
> 
>   [1] https://github.com/shu-mutou/ui-cookiecutter
>   [2] https://etherpad.openstack.org/p/horizon-ocata-priorities
> 
>   Regards,
> 
>   Shu Muto
> 
> 
>   __
> 
>   OpenStack Development Mailing List (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] Finish test job transition to Ubuntu Xenial

[Clark Boylan]

On Mon, Nov 14, 2016, at 05:21 PM, Neil Jerram wrote:
> On Mon, Nov 7, 2016 at 9:50 PM Clark Boylan  wrote:
> 
> > If you have jobs still running on trusty the next step is to fire up a
> > Xenial instance locally and run that test to see if it works.
> >
> 
> Can you advise how big (RAM, CPU, disk) the Xenial instance should be, so
> as to be similar to what is used in the gate?

Working on documenting that at
https://review.openstack.org/#/c/394566/1/doc/source/testing.rst still a
bit of a work in progress overall but should include those specifics.

Clark

__
OpenStack Development Mailing 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] Finish test job transition to Ubuntu Xenial

[Neil Jerram]

On Mon, Nov 7, 2016 at 9:50 PM Clark Boylan  wrote:

> If you have jobs still running on trusty the next step is to fire up a
> Xenial instance locally and run that test to see if it works.
>

Can you advise how big (RAM, CPU, disk) the Xenial instance should be, so
as to be similar to what is used in the gate?

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

Re: [openstack-dev] [gnocchi] new measures backlog scheduling

[gordon chung]

On 14/11/16 05:53 PM, John Dickinson wrote:
>
> I'm stepping in to an area here (gnocchi) that I know very little about,
> so please forgive me where I mess up.
>
> First, as a practical note, stuff in Swift will be /much/ better when
> you spread it across the entire namespace. It's a lot better to data
> stored in many containers instead of putting all data into just one
> container. Spreading the data out takes advantages of Swift's scaling
> characteristics and makes users and ops happier.

thanks for the tip John! good to know the proposal might actually have 
additional benefits.

>
> Second, at the risk of overgeneralizing[1], you may want to consider
> using the consistent hashing code from Ironic and Nova (and is being
> discussed as a new oslo library). Consistent hashing gives you the nice
> property of being able to change the number of buckets you're hashing
> data into without having to rehash most of the existing data. Think of
> it this way, if you hash into two buckets and use even/odd (i.e. last
> bit) to determine which bucket data goes into, then when you need a
> third bucket you have to switch to MOD 3 and two-thirds of your existing
> data will move into a different bucket. That's bad, and it gets even
> worse as you add more and more buckets. With consistent hashing, you can
> get the property that if you add 1% more buckets, you'll only move about
> 1% of the existing data to a different bucket.

is the consistent hashing code == hashring code? we actually jacked that 
from Ironic and used it in Ceilometer already. :) but that's a good idea 
to leverage it in this case if we proceed. i just noticed jd adding it 
to tooz[1].

>
> So going even further into my ignorance of the gnocchi problem space, I
> could imagine that there may be some benefit of being able to change the
> number of hash buckets over time based on how many items, how many
> workers are processing them, rate of new metrics, etc. If there's
> benefit to changing the number of hash buckets over time, then looking
> at consistent hashing is probably worth the time. If there is no benefit
> to changing the number of hash buckets over time, then a simple
> |hash(data) >> (hash_len - log2(num_hash_buckets) + 1)| or |hash(data)
> MOD num_hash_buckets| is probably sufficient.

that's a good point. in Ceilometer, iirc we don't ever change the number 
of buckets so we arguably didn't need it. in this case, i imagine we'd 
need to consider overhead of creating a lot of buckets vs letting users 
attempt to figure out what the right number of buckets is for their system.

thanks for all the info! glad your filter is picking up keywords in 
email body.

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

cheers,
-- 
gord

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

Re: [openstack-dev] [nova] Problem with Quota and servers spawned in groups

[melanie witt]

On Mon, 14 Nov 2016 17:34:28 -0600, Matt Riedemann wrote:

Why do we want to return a list of uuids for servers created? I thought
that's why we have the 'return_reservation_id' request parameter for the
server multiple-create scenario so that you can get a single reservation
ID back and all of the servers created are using that same
reservation_id and then you can query them by that later if you want to
list them out.


As far as I know, doing that would be a nice-to-have for people using 
multi-create, so they get the uuids in one step instead of having to do 
a second query for them using the reservation_id. It's not technically 
necessary and I don't think it's related to this multi-create quota 
behavior issue.


-melanie




__
OpenStack Development Mailing 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] Problem with Quota and servers spawned in groups

[melanie witt]

On Mon, 14 Nov 2016 22:48:01 +0100, Sławek Kapłoński wrote:

Are You sure that but
https://bugs.launchpad.net/nova/+bug/1458122 is still valid? I tried to
spawn instances with min=3 and max=11 when quota was set to 10 and I had
spawned 10 instances properly (no any in error state). I also checked it
with givin only max=11 (no min value, so set to 1 by default) and I had
also 10 instances spawned.

All results of my tests can be found in http://pastebin.com/Te71HJ8q if
You want.


Yeah, according to the data Sławek gathered, the behavior changed from 
what's described in bug 1458122 at some point, without a spec. I have 
intended to dig in and find out what happened so we can at least cite 
the commit that changed the behavior in the commit message for this 
server groups quota change, and close out the other bug if it's no 
longer valid. It would be helpful if anyone else can take a look too.


-melanie


__
OpenStack Development Mailing 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] Problem with Quota and servers spawned in groups

[Matt Riedemann]

On 11/14/2016 11:03 AM, Chris Friesen wrote:

3) returning the uuids of all instances booted as a result of the
multiboot API call


Why do we want to return a list of uuids for servers created? I thought 
that's why we have the 'return_reservation_id' request parameter for the 
server multiple-create scenario so that you can get a single reservation 
ID back and all of the servers created are using that same 
reservation_id and then you can query them by that later if you want to 
list them out.


--

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] [All] Finish test job transition to Ubuntu Xenial

[Clark Boylan]

On Mon, Nov 7, 2016, at 01:48 PM, Clark Boylan wrote:
> Hello everyone,
> 
> The infra team would really like to get the Ubuntu Xenial for testing
> transition completed early this cycle. We are planning to switch any
> jobs that remain on Ubuntu Trusty but should be on Ubuntu Xenial on
> December 6, 2016. That gives us about a month from today to more
> gracefully migrate jobs while still getting it done early enough in the
> cycle to fix any issues and put it behind us. Would be great for project
> teams to test if their jobs run on Xenial and propose updates to
> openstack-infra/project-config as necessary to switch to Ubuntu Xenial.

Just a friendly reminder that this is still happening. We will be
updating any jobs running on Trusty that should be running on Xenial on
December 6th. I have seen a few projects jump on this and start making
the necessary changes. Thank you for doing that!

As always feel free to ask questions or ping us (the infra team) for
help if you need it. 

Clark

__
OpenStack Development Mailing 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] Fedora AArch64 (64-bit ARM) support in diskimage-builder

[dmarlin]

On 11/14/2016 04:40 PM, Ben Nemec wrote:



On 11/11/2016 10:55 AM, dmar...@redhat.com wrote:


I have been looking at using diskimage-builder on Fedora AArch64. While
there is 64-bit ARM support for Ubuntu (arm64), there appear to be a few
things missing for Fedora.  Is this the correct list to ask questions,
and propose minor changes to diskimage-builder in support of this 
effort?


Yes.  I would suggest you tag your emails with [diskimage-builder] so 
the relevant people are more likely to see them.


Will do.


Thank you for the feedback,

d.marlin


__
OpenStack Development Mailing 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] [gnocchi] new measures backlog scheduling

[John Dickinson]

On 14 Nov 2016, at 13:57, gordon chung wrote:

> hi,
>
> one issue i've noticed with our 'backlog' scheduling is that we register
> all our new measures in a single folder/filestore object. this folder or
> object in most production cases can grow quite large (tens/hundreds of
> thousands). so we don't load it all into memory, the drivers will only
> grab the first x items and process them. unfortunately, we don't control
> the ordering of the returned items so it is dependent on the ordering
> the backend returns. for Ceph, it returns in what i guess is some
> alphanumeric order. the file driver i believe returns based on how the
> filesystem indexes files. i have no idea how swift ordering behaves. the

Listings in Swift are lexicographically sorted by the object name.

> result of this is that we may starve some new measures from being
> processed because they keep getting pushed back by more recent measures
> if less agents are deployed.
>
> with that said, this isn't a huge issue because measures can be
> processed on demand using refresh parameter but it's not ideal.
>
> i was thinking, to better handle processing while minimising the effects
> of a driver's natural indexing, we can hash our new measures into
> buckets based on metric_id. Gnocchi would hash all incoming metrics into
> 100? buckets and metricd agents would divide up these buckets and loop
> through them. this would ensure we have smaller buckets to deal with and
> therefore less chance, metrics get pushed back and starved. that said it
> will add additional requirements of 100? folders/filestore objects
> rather than 1. it will also mean we may be making significantly more
> smaller fetches vs single (possibly) giant fetch.
>
> to extend this, we could also hash into project_id groups and thus allow
> some projects to have more workers and thus more performant queries?
> this might be too product tailored. :)

I'm stepping in to an area here (gnocchi) that I know very little about, so 
please forgive me where I mess up.

First, as a practical note, stuff in Swift will be *much* better when you 
spread it across the entire namespace. It's a lot better to data stored in many 
containers instead of putting all data into just one container. Spreading the 
data out takes advantages of Swift's scaling characteristics and makes users 
and ops happier.

Second, at the risk of overgeneralizing[1], you may want to consider using the 
consistent hashing code from Ironic and Nova (and is being discussed as a new 
oslo library). Consistent hashing gives you the nice property of being able to 
change the number of buckets you're hashing data into without having to rehash 
most of the existing data. Think of it this way, if you hash into two buckets 
and use even/odd (i.e. last bit) to determine which bucket data goes into, then 
when you need a third bucket you have to switch to MOD 3 and two-thirds of your 
existing data will move into a different bucket. That's bad, and it gets even 
worse as you add more and more buckets. With consistent hashing, you can get 
the property that if you add 1% more buckets, you'll only move about 1% of the 
existing data to a different bucket.

So going even further into my ignorance of the gnocchi problem space, I could 
imagine that there may be some benefit of being able to change the number of 
hash buckets over time based on how many items, how many workers are processing 
them, rate of new metrics, etc. If there's benefit to changing the number of 
hash buckets over time, then looking at consistent hashing is probably worth 
the time. If there is no benefit to changing the number of hash buckets over 
time, then a simple `hash(data) >> (hash_len - log2(num_hash_buckets) + 1)` or 
`hash(data) MOD num_hash_buckets` is probably sufficient.

--John



[1] I've got a nice hammer. Your problem sure looks like a nail to me.

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


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] Fedora AArch64 (64-bit ARM) support in diskimage-builder

[Ben Nemec]

On 11/11/2016 10:55 AM, dmar...@redhat.com wrote:


I have been looking at using diskimage-builder on Fedora AArch64. While
there is 64-bit ARM support for Ubuntu (arm64), there appear to be a few
things missing for Fedora.  Is this the correct list to ask questions,
and propose minor changes to diskimage-builder in support of this effort?


Yes.  I would suggest you tag your emails with [diskimage-builder] so 
the relevant people are more likely to see them.


__
OpenStack Development Mailing List (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] [gnocchi] new measures backlog scheduling

[gordon chung]

hi,

one issue i've noticed with our 'backlog' scheduling is that we register 
all our new measures in a single folder/filestore object. this folder or 
object in most production cases can grow quite large (tens/hundreds of 
thousands). so we don't load it all into memory, the drivers will only 
grab the first x items and process them. unfortunately, we don't control 
the ordering of the returned items so it is dependent on the ordering 
the backend returns. for Ceph, it returns in what i guess is some 
alphanumeric order. the file driver i believe returns based on how the 
filesystem indexes files. i have no idea how swift ordering behaves. the 
result of this is that we may starve some new measures from being 
processed because they keep getting pushed back by more recent measures 
if less agents are deployed.

with that said, this isn't a huge issue because measures can be 
processed on demand using refresh parameter but it's not ideal.

i was thinking, to better handle processing while minimising the effects 
of a driver's natural indexing, we can hash our new measures into 
buckets based on metric_id. Gnocchi would hash all incoming metrics into 
100? buckets and metricd agents would divide up these buckets and loop 
through them. this would ensure we have smaller buckets to deal with and 
therefore less chance, metrics get pushed back and starved. that said it 
will add additional requirements of 100? folders/filestore objects 
rather than 1. it will also mean we may be making significantly more 
smaller fetches vs single (possibly) giant fetch.

to extend this, we could also hash into project_id groups and thus allow 
some projects to have more workers and thus more performant queries? 
this might be too product tailored. :)

thoughts?

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

Re: [openstack-dev] [api]

[Edward Leafe]

On Nov 14, 2016, at 3:14 PM, Ed Leafe  wrote:

> Since we already had ‘new’, I thought that ‘nin’ would be consistent. No 
> other reason to prefer it, though.

s/new/neq

Damn you autocorrect!

-- Ed Leafe






__
OpenStack Development Mailing 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] Problem with Quota and servers spawned in groups

[Sławek Kapłoński]

Hello,

I remember that Melanie told me that there was another issues there and
I talked with her to check all cases. Are You sure that but
https://bugs.launchpad.net/nova/+bug/1458122 is still valid? I tried to
spawn instances with min=3 and max=11 when quota was set to 10 and I had
spawned 10 instances properly (no any in error state). I also checked it
with givin only max=11 (no min value, so set to 1 by default) and I had
also 10 instances spawned.

All results of my tests can be found in http://pastebin.com/Te71HJ8q if
You want.

I agree that it would be nice to e.g. return uuids of all instances but
is really necessary specs to fix this issue which I reported (and IMHO
only inconsistency there)?

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl

On Mon, 14 Nov 2016, Chris Friesen wrote:

> On 11/11/2016 07:07 AM, Sławek Kapłoński wrote:
> > Hello,
> > 
> > Can maybe someone (from core team) take a look on that? Thx in advance :)
> 
> 
> As Melanie Witt mentioned on your bug report, there are a number of issues
> around multi-boot.   (I reported
> https://bugs.launchpad.net/nova/+bug/1458122 last year, for example.)
> 
> Getting rid of multi-boot has been proposed a number of times but was shot
> down on efficiency arguments.
> 
> In order to improve this someone needs to write up a spec to make the whole
> multi-boot story coherent.  At a minimum this would need to address:
> 
> 1) the quota issue you raised
> 2) the partial completion issue I raised
> 3) returning the uuids of all instances booted as a result of the multiboot 
> API call
> 
> Since it means a spec, probably nothing will happen in Ocata...we could
> maybe see about Pike.
> 
> Chris
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [ironic] this week's priorities and subteam reports

[Loo, Ruby]

Hi,

We are nerdy to present this week's subteam report for Ironic. As usual, this 
is pulled directly from the Ironic whiteboard[0] and formatted.

NEW! Starting today, we will also include the week's priorities (also available 
from the whiteboard[0]). The priorities are decided at Monday's weekly meeting 
[1], after reviewing the subteam reports.

This Week's Priorities (as of the weekly ironic meeting)

- portgroup: review code 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1618754
- attach/detach: review code (after sambetts updates): 
https://review.openstack.org/#/c/327046/
- boot from volume: review volume connection work: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1526231
- next notifications: review code: 
https://review.openstack.org/#/q/topic:bug/1606520
- root device hints: review code (after lucasagomes updates): 
https://review.openstack.org/#/c/386714/
- getting tests out of tempest tree
- next driver comp patch (database foo) to review: 
https://review.openstack.org/396681
- rolling upgrades spec needs reviews: https://review.openstack.org/#/c/299245/

Bugs (dtantsur)
===
- Stats (diff between 07 Nov 2016 and 14 Nov 2016)
- Ironic: 233 bugs + 220 wishlist items (+2). 35 new (+2), 181 in progress 
(+1), 1 critical, 27 high (-1) and 23 incomplete
- Inspector: 12 bugs (-1) + 21 wishlist items. 2 new (-1), 10 in progress (+1), 
0 critical, 1 high and 2 incomplete (-1)
- Nova bugs with Ironic tag: 11. 0 new (-1), 0 critical, 1 high

Portgroups support (sambetts, vdrok)

* trello: https://trello.com/c/KvVjeK5j/29-portgroups-support
- status as of most recent weekly meeting:
- yet another multitenancy spec update, configuration-related fields in 
portgroup objects - https://review.openstack.org/396610
- portgroups patches need reviews: 
https://review.openstack.org/#/q/topic:bug/1618754
- portgroup spec (in nova) needs approval before nova spec freeze deadline 
Nov 17: https://review.openstack.org/#/c/387534/

CI refactoring (dtantsur, lucasagomes)
==
* trello: https://trello.com/c/c96zb3dm/32-ci-refactoring
- status as of most recent weekly meeting:
- (lucasagomes) Gate has switched jobs to run on Xenial + ipmitool (merged 
already)
- (dtantsur) Making more jobs voting: 
https://review.openstack.org/#/c/397164/
- (lucasagomes) Patch to disable iPXE in favor of testing standard PXE in 
the postgres job: https://review.openstack.org/#/c/397129/
- (lucasagomes) Patch to switch the postgres job to ipmitool: 
https://review.openstack.org/#/c/397160/
- 2016-11-08: pep8 jobs (jlvillal): 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106668.html
- ironic-python-agent passes new pep8 job: 
http://logs.openstack.org/23/395123/2/experimental/experimental-ironic-python-agent-pep8-ubuntu-xenial/b8e761c/
- ironic passes new pep8 job: 
http://logs.openstack.org/02/395102/3/experimental/experimental-ironic-pep8-ubuntu-xenial/891b1ce/
- python-ironicclient passes new pep8 job: 
http://logs.openstack.org/99/382999/4/experimental/experimental-python-ironicclient-pep8-ubuntu-xenial/5c78e08/
- ironic-inspector passes new pep8 job: 
http://logs.openstack.org/98/395598/1/experimental/experimental-ironic-inspector-pep8-ubuntu-xenial/0ea1c1a/

Rolling upgrades and grenade-partial (rloo, jlvillal)
=
* trello: 
https://trello.com/c/GAlhSzLm/2-rollindg-upgrades-and-grenade-with-multi-node
- status as of most recent weekly meeting:
- spec was updated, needs reviews: https://review.openstack.org/299245
- Work is ongoing for enabling Grenade with multi-tenant: 
https://review.openstack.org/389268
- Discovered issue in project-config settings that ironic devstack 
plugin enabled twice.
- Fix proposed: https://review.openstack.org/396802 in project-config

Security groups (jroll)
===
* trello: 
https://trello.com/c/klty7VVo/30-security-groups-for-provisioning-cleaning-network
- status as of most recent weekly meeting:
- Very close to being merged needs reviews: 
https://review.openstack.org/#/c/361451/

Interface attach/detach API (sambetts)
==
* trello: https://trello.com/c/nryU4w58/39-interface-attach-detach-api
- status as of most recent weekly meeting:
- Spec merged and Nova BP approved
- Code patches need updates to align with most recent version of the spec
- Ironic - https://review.openstack.org/327046
- Nova - https://review.openstack.org/364413
- IronicClient - https://review.openstack.org/364420

Generic boot-from-volume (TheJulia)
===
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- 

Re: [openstack-dev] [ironic] python-wsmanclient future

[Richard.Pioso]

Hi,

A strong case has been made for abandoning the python-wsmanclient project.

Barring further information or another, more compelling argument from the 
community, my team supports the proposal to abandon it.

Rick

-Original Message-
From: Dmitry Tantsur [mailto:dtant...@redhat.com] 
Sent: Monday, November 07, 2016 8:52 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [ironic] python-wsmanclient future

Hi folks!

In view of the Ironic governance discussion [1] I'd like to talk about 
wsmanclient [2] future.

This project was created to split away wsman code from python-dracclient to be 
reused in other drivers (I can only think of AMT right now). This was never
finished: dracclient still uses its internal wsman implementation.

To make it worse, the guy behind this effort (ifarkas) has left our team, 
python-dracclient is likely to leave Ironic governance per [1], and the AMT 
driver is going to leave the Ironic tree.

At least the majority of the folks currently behind dracclient (Miles, Lucas and
myself) do not have resources to continue this wsmanclient effort. Unless 
somebody is ready to take over both wsmanclient itself and the effort to port 
dracclient, I suggest we abandon wsmanclient.

Any thoughts?

[1] https://review.openstack.org/#/c/392685/
[2] https://github.com/openstack/python-wsmanclient

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

[Ed Leafe]

On Nov 14, 2016, at 2:52 PM, Ian Cordasco  wrote:

> not_in is nice and explicit while nin and out are a bit, more clever. I think 
> we should avoid trying to be clever.

Since we already had ‘new’, I thought that ‘nin’ would be consistent. No other 
reason to prefer it, though.

> That said, what about something like
> 
> state=!in:x,y,z
> 
> This just makes me nervous that we're beginning to define our own query 
> language.

Ugh - let’s not do that!


-- Ed Leafe






__
OpenStack Development Mailing List (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] [new][openstackclient] os-client-config 1.24.0 release (ocata)

[no-reply]

We are tickled pink to announce the release of:

os-client-config 1.24.0: OpenStack Client Configuation Library

This release is part of the ocata release series.

The source is available from:

http://git.openstack.org/cgit/openstack/os-client-config

Download the package from:

https://pypi.python.org/pypi/os-client-config

Please report issues through launchpad:

http://bugs.launchpad.net/os-client-config

For more details, please see below.

Changes in os-client-config 1.23.0..1.24.0
--

e2a593d Revert "Remove validate_auth_ksc"


Diffstat (except docs and test files)
-

os_client_config/config.py | 71 --
4 files changed, 76 insertions(+), 45 deletions(-)




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

Re: [openstack-dev] [api]

[Ian Cordasco]

-Original Message-
From: Ed Leafe 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: November 14, 2016 at 11:29:59
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [api]

> On Nov 14, 2016, at 6:04 AM, milanisko k wrote:
>  
> > I'd like to ask about possible ``=in:``[1] operator negation implementation
> > Should the implementation be a negative field name such as 
> > ``?state=in:a,b,c¬_state=in:x,y,z``?  
> > Or rather a negated operator: ``?state=in:a,b,c=not_in:x,y,z``?
> > There already is the ``=neq:`` operator specified in the filtering spec[1], 
> > so I guess  
> ``=not_in:/=nin:/=out:`` might be more appropriate?
>  
> The latter looks better to me. I’d like to get feedback on the exact choice 
> of ``=not_in:/=nin:/=out:``  
> to recommend. Personally, I prefer ‘nin’, but I’ll defer to others on that.

not_in is nice and explicit while nin and out are a bit, more clever. I think 
we should avoid trying to be clever.

That said, what about something like

    state=!in:x,y,z

This just makes me nervous that we're beginning to define our own query 
language.

--  
Ian Cordasco


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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Ian Cordasco]

-Original Message-
From: Michał Jastrzębski 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: November 14, 2016 at 09:54:48
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

> Logistically it would be best to make this one file GPLv3. No other
> files would need to be GPLv3 in Kolla as this is only one that will be
> derivative, rest of Kolla will be safe because of subprocess
> separation. Who would be able to say whether or not it's possible to
> put single GPLv3 file into otherwise ASL repository? We don't have any
> other project with multiple licenses in it? What would LICENSE file in
> github show? Do we need to mention parts of GPL there?

How something displays on GitHub should be the very last concern any OpenStack 
project has.

GitHub is not the canonical source of truth for an OpenStack project, 
https://git.openstack.org/cgit/openstack/ is. The questions here 
should be purely legal, not how something displays on a mirrored location.

--  
Ian Cordasco


__
OpenStack Development Mailing List (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] [networking_ovn] router not loading

[Murali R]

I get this error after configuring neutron & restart server for
networking_ovn with L3 using ovn_l3. Why is it not recognizing the class
that is there?

2016-11-14 12:12:12.001 12922 ERROR neutron ImportError: Plugin
'networking_ovn.l3.l3_ovn.OVNL3RouterPlugin' not found.


The file l3_ovn.py is having that definition at
$ ls -l /usr/lib/python2.7/dist-packages/networking_ovn/l3/
...
-rw-r--r-- 1 root root 0 Nov 14 11:39 __init__.py
-rw-r--r-- 1 root root   149 Oct 31 14:57 __init__.pyc
-rw-r--r-- 1 root root  9649 Nov 14 11:39 l3_ovn_admin_net.py
-rw-r--r-- 1 root root 43603 Nov 14 11:39 l3_ovn.py
-rw-r--r-- 1 root root  9968 Oct 31 14:57 l3_ovn.pyc
...


Configuration:
neutron.conf

core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin
...
service_plugins = networking_ovn.l3.l3_ovn.OVNL3RouterPlugin
...

I did not make any changes to egg-info that has openstack router entry in
entry_points.py
__
OpenStack Development Mailing 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] [manila] spec detail of IPv6's export locations

[Ben Swartzlander]

On 11/13/2016 10:03 PM, TommyLike Hu wrote:

Hey manila memebers and driver maintainers,
  I wanna set up an new thread to talk about the proper and
better exprienced way for both end users and drivers who want use or
support IPv6 in manila, and I wish this can be discussed and optimised
before the spec[1] can get ready to the next review.
 The issue was initial raise by Ben Swartzlander on the manila
IPv6 spec[1] (please check PS9 line 56), and this draft only state the
export_location part which is currently fully focused in the spec.

*proposed changes**(Based on Bens' comments)** are below*:
1.  Add new share type extra_spec 'ip_version' that can indicate the
access ip version:
  * ip_version = '4' or '6' or '4&6'*. default without declaration is '4'.
2. Drivers have to report the capabilties with the ip versions that it
can support, the capability is report
   in the form: *support_ip_versions = '4' or '6' or '4&6'*. default
without override is '4'


I think I'd prefer 2 extra specs: one for v4 and one for v6. Two 
booleans seems cleaner than an enum string



3. The ip versions of share type's, driver supported's and share
network's will be all checked whether
   they matched before the creating of new share.


It should be mentioned that this won't require any new code. The 
existing filters in the scheduler can handle this.



4. Driver will export the locations according the share-network's ip
version.


Share networks only affect DHSS=true share types, and the share networks 
already have support for IPv6 because they just refer to a neutron 
subnet. What's missing is handling for IPv6 during creation of the share 
servers.



5. (About access rules)the ip versions of share type's and access host's
will be also checked.


This is a good idea I hadn't thought about. It probably doesn't make 
sense to allow v6 rules for a v4-only share, and similarly it might not 
make sense to allow v4 rules for a v6-only share.


What makes this complicated however is that support can change over 
time. A share that was created on a v4-only backend, could later get 
IPv6 support added. Looking at the share type won't give you the right 
answer -- you have to look at the export locations. We might want to 
enforce that drivers tell the share manager which export locations are 
v4/v6 explicitly.



Please leave any comments about your concern or just which is not clear
or missed  here.

Thanks
TommyLike.Hu

[1] https://review.openstack.org/#/c/362786/9/specs/ocata/manila-ipv6.rst


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




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

Re: [openstack-dev] [ironic] Removing agent vendor passthru and unsupported drivers

[Jim Rollenhagen]

On Mon, Nov 14, 2016 at 1:34 PM,   wrote:
> Agree with removal of unsupported drivers.
> For supported drivers we will still need to support passthru.
> First, because it is currently used by many customers and for many drivers.
> Second, we will need to add support in Ironic and expose it in API for many 
> features before we can do them without passthru crutch.
> For example, PXE NIC setup support, FW install/update, BIOS version 
> setup/upgrade, etc.

To be clear, this thread is about the lookup and heartbeat vendor
passthru methods, not
removing all of vendor passthru.

// jim

>
> Thanks,
> Arkady
>
>
> -Original Message-
> From: Mathieu Mitchell [mailto:mmitch...@internap.com]
> Sent: Monday, November 14, 2016 10:42 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [ironic] Removing agent vendor passthru and 
> unsupported drivers
>
> Hi Pavlo,
>
> See my reply below.
>
> On 2016-11-14 7:50 AM, Pavlo Shchelokovskyy wrote:
>> Hi Ironicers,
>>
>> currently I'm busy with removing the lookup/heartbeats "as vendor passthru"
>> from Ironic which we slated for removal in Ocata, and have the
>> following question.
>>
>> Removing the old agent vendor passthru requires changes to some
>> unsupported drivers whose copies are already in
>> ironic-staging-drivers. The drivers in question are WoL, iBoot and
>> especially AMT (which uses a custom not-so-vendor passthru).
>
> The "follows-standard-deprecation" policy states the following "Features, 
> APIs or configuration options are marked deprecated in the code. Appropriate 
> warnings will be sent to the end user, operator or library user. **Code will 
> be frozen and only receive minimal maintenance (just so that it continues to 
> work as-is).**" [0] (emphasis mine). My understanding is that your changes 
> would fall into the "just so that it continues to work as-is" clause.
>
>>
>> AFAIU according to our third-party drivers policy, those unsupported
>> drivers have to be removed from Ironic tree anyway (as there is no
>> plan to test them on third-party CI AFAIK) and this looks like a
>> perfect time to do it.
>>
>> So ideally I'd like to fix those in ironic-staging-drivers and then
>> remove them from Ironic tree via a depends-on patch.
>>
>> What do you think on such plan?
>
> The drivers were marked for removal in Ocata [1], so you can already remove 
> them from the tree. A simple but relevant thing I note is that it would be 
> preferable, from my point of view, to remove them all in a single commit.
>
> Finally, I would add that functional CI coverage for the SNMP driver is well 
> under way [2]. We are currently doing the work to keep the SNMP driver 
> in-tree (what we are doing is similar to VirtualBMC and the IPMI driver). 
> Going ahead with a single commit to remove all the drivers would impact our 
> current work. I would therefore suggest doing the required "vendor passthru" 
> changes to the different drivers and post-pone the commit to delete all 
> unsupported drivers.
>
> [0]
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
> [1] http://docs.openstack.org/releasenotes/ironic/current-series.html#id5
> [2] https://review.openstack.org/#/q/status:open+topic:bug/1597793
>
> Thank you,
> Mathieu Mitchell
> Internap
>
>>
>> Cheers,
>> 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

__
OpenStack Development Mailing 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][fwaas] neutron-fwaas meeting time change

[Nate Johnston]

On Sat, Oct 29, 2016 at 08:41:42AM +, Nate Johnston wrote:
> Hello neutron-fwaas team,
> 
> With the expiration of Daylight Savings Time imminent in the USA, I would like
> to propose that we change the meeting time for the neutron-fwaas IRC meeting
> from the current value of 0400 UTC.  Here are a few proposals:
> 
> First proposed time: 1300 UTC
> Tokyo (UTC+0900): 10:00 PM
> Bengaluru (UTC+0530): 6:30 PM
> US Eastern (UTC-0400): 9:00 AM
> US Pacific (UTC-0700): 6:00 AM

This was the option agreed to in the team meeting[1], and in the team meeting a
preference for Thursday was expressed.  That is however a popular timeslot, and
so there are no available channels at that time on Wednesday or Thursday.  

What would be the best day for a meeting: Monday or Tuesday?

Let's keep to the old meeting time until the meeting time change[2] merges.

Thanks!

--N.

[1] 
http://eavesdrop.openstack.org/meetings/fwaas/2016/fwaas.2016-11-02-04.00.log.html#l-105
[2] https://review.openstack.org/#/c/393793/


__
OpenStack Development Mailing 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] ui-cookiecutter

[Thai Q Tran]

Hi Shuu,
 
Sorry for the delay again, I just got back from vacation. I think your cookiecutter will be useful in a number of ways.
 
1. We can use it to easily generate plugins for beginners
2. We can use it in Horizon's startdash command (have to look into this) for internal use
 
Ideally, the project should be under an OpenStack repo so horizon drivers can maintain it. Lets make it a point and bring it up at the horizon weekly meeting. We can proceed after community feedback.
 
- Original message -From: Shuu Mutou To: "openstack-dev@lists.openstack.org" Cc: Haruhiko Katou Subject: [openstack-dev] [Horizon] ui-cookiecutterDate: Tue, Nov 8, 2016 1:24 AM 
Hi Horizoners,Thanks for picking up ui-cookiecutter[1] and setting Ocata-2 milestone at summit[2].Thai or Cindy? Thank you!!I'm maintaining ui-cookiecutter, but I'm ready for transferring it as Horizon subproject.Can I start to create subproject for ui-cookiecutter?Or please let me know what I should do.[1] https://github.com/shu-mutou/ui-cookiecutter[2] https://etherpad.openstack.org/p/horizon-ocata-prioritiesRegards,Shu Muto__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

Re: [openstack-dev] [ironic] Removing agent vendor passthru and unsupported drivers

[Arkady.Kanevsky]

Agree with removal of unsupported drivers.
For supported drivers we will still need to support passthru.
First, because it is currently used by many customers and for many drivers.
Second, we will need to add support in Ironic and expose it in API for many 
features before we can do them without passthru crutch.
For example, PXE NIC setup support, FW install/update, BIOS version 
setup/upgrade, etc.

Thanks,
Arkady


-Original Message-
From: Mathieu Mitchell [mailto:mmitch...@internap.com] 
Sent: Monday, November 14, 2016 10:42 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [ironic] Removing agent vendor passthru and 
unsupported drivers

Hi Pavlo,

See my reply below.

On 2016-11-14 7:50 AM, Pavlo Shchelokovskyy wrote:
> Hi Ironicers,
>
> currently I'm busy with removing the lookup/heartbeats "as vendor passthru"
> from Ironic which we slated for removal in Ocata, and have the 
> following question.
>
> Removing the old agent vendor passthru requires changes to some 
> unsupported drivers whose copies are already in 
> ironic-staging-drivers. The drivers in question are WoL, iBoot and 
> especially AMT (which uses a custom not-so-vendor passthru).

The "follows-standard-deprecation" policy states the following "Features, APIs 
or configuration options are marked deprecated in the code. Appropriate 
warnings will be sent to the end user, operator or library user. **Code will be 
frozen and only receive minimal maintenance (just so that it continues to work 
as-is).**" [0] (emphasis mine). My understanding is that your changes would 
fall into the "just so that it continues to work as-is" clause.

>
> AFAIU according to our third-party drivers policy, those unsupported 
> drivers have to be removed from Ironic tree anyway (as there is no 
> plan to test them on third-party CI AFAIK) and this looks like a 
> perfect time to do it.
>
> So ideally I'd like to fix those in ironic-staging-drivers and then 
> remove them from Ironic tree via a depends-on patch.
>
> What do you think on such plan?

The drivers were marked for removal in Ocata [1], so you can already remove 
them from the tree. A simple but relevant thing I note is that it would be 
preferable, from my point of view, to remove them all in a single commit.

Finally, I would add that functional CI coverage for the SNMP driver is well 
under way [2]. We are currently doing the work to keep the SNMP driver in-tree 
(what we are doing is similar to VirtualBMC and the IPMI driver). Going ahead 
with a single commit to remove all the drivers would impact our current work. I 
would therefore suggest doing the required "vendor passthru" changes to the 
different drivers and post-pone the commit to delete all unsupported drivers.

[0]
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
[1] http://docs.openstack.org/releasenotes/ironic/current-series.html#id5
[2] https://review.openstack.org/#/q/status:open+topic:bug/1597793

Thank you,
Mathieu Mitchell
Internap

>
> Cheers,
> 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] [tc][kolla] Ansible module with GPLv3

[Jeremy Stanley]

On 2016-11-14 11:11:09 -0500 (-0500), Zane Bitter wrote:
[...]
> I think the DCO process makes things much clearer though. It's
> quite easy to understand that contributions to an ASL2-licensed
> repo are ASL2 and contributions to a GPL-licensed repo are GPL.
[...]

Well, it bears pointing out that the only way we got BoD support for
using the DCO was based on an understanding that employed
contributors would be covered by separate Corporate Contributor
License Agreements[0] anyway. As for the text of the DCO[1], it can
quite easily be interpreted (and is my personal interpretation) that
you're agreeing your contributions fall under the same license as
claimed in each file to which you're contributing, and is not a
repository-wide statement of license at all.

> The TC has adopted an official policy that explicitly excludes
> both GPL code and code that imports GPL code from official
> repositories. If you think the policy is too conservative (and it
> is quite conservative) then you're on the TC... change it. Until
> then we don't need legal reasons to force us to follow our policy.
> It's our policy. That's enough.

Don't make the mistake of thinking I'm unaware. I completely agree
that we (the OpenStack contributor community) don't need legal
reasons to enforce a policy that we've ratified. My point was that
we're already taking a very fuzzy stance by special-casing "tools
that are run with or on OpenStack projects only during validation or
testing phases of development"[2] because it's become increasingly
evident that a strict position on this is unsustainable. This thread
brings another excellent example for where the status quo is failing
us, and provides an opportunity to evaluate its ramifications and
possible future adjustments (and what I expect will become a
never-ending list of exceptions unless we reevaluate our priorities
here).

[0] 
https://wiki.openstack.org/wiki/Governance/Foundation/26Oct2015BoardMeetingMinutes
[1] http://docs.openstack.org/infra/manual/developers.html#using-signed-off-by
[2] http://governance.openstack.org/reference/licensing.html
-- 
Jeremy Stanley


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

Re: [openstack-dev] [glance] priorities for O-1

[Bashmakov, Alexander]

Please take note of another patch related to the list below:

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

This one updates the existing Community Images spec with implementation details 
and justification for the design decision to make image visibility default to 
'shared'.

Regards,
Alex

-Original Message-
From: Ian Cordasco [mailto:sigmaviru...@gmail.com] 
Sent: Monday, November 14, 2016 9:58 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [glance] priorities for O-1

-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: November 10, 2016 at 08:32:51
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  [openstack-dev] [glance] priorities for O-1

> Hello Glancers,
>
> O-1 is around the corner (i.e., next week). The priority for Glance is 
> Community Images.
>
> Please review the following patches:
>
> https://review.openstack.org/#/c/369110/
> https://review.openstack.org/#/c/387660/
> https://review.openstack.org/#/c/391968/

Glance reviewers,

Please prioritize reviewing the above patches. These are the highest priority 
items for Ocata-1 and need to merge so we can stabilize them throughout the 
rest of this very short cycle.

I will be proposing a review to openstack/releases to tag Ocata-1. For now, I 
will block the workflow, but on Thursday, I will update it and encourage the 
Release team to move forward with it regardless of whether these have merged or 
not. While these are a priority, as Release Czar I cannot force you to review 
them but I must move forward with our release plans.

Cheers,
--
Ian Cordasco

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

[Adrian Otto]

Ruben,

I found the following two reviews:

https://review.openstack.org/397150 Magnum_driver for congress
https://review.openstack.org/397151 Test for magnum_driver

Are these what you are referring to, or is it something else?

Thanks,

Adrian


> On Nov 14, 2016, at 4:13 AM, Ruben  wrote:
> 
> Hi everybody,
> I've added the magnum_driver code, that I'm trying to write for congress, to 
> review.
> I think that I've made some errors.
> 
> I hope in your help.
> Ruben
> 
> __
> OpenStack Development Mailing List (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] diskimage-builder 01-override-yum-arch question

[dmarlin]

I was looking at 01-override-yum-arch in diskimage-builder, and have a 
question.


Is the following code correct in git, or should $arch be written into 
/etc/dnf/vars/arch, similar to the yum path (for F22 and older) as shown 
below?


--- a/elements/rpm-distro/pre-install.d/01-override-yum-arch
+++ b/elements/rpm-distro/pre-install.d/01-override-yum-arch
@@ -28,7 +28,7 @@ fi
 if [[ $DISTRO_NAME == "fedora" && $DIB_RELEASE -ge 22 ]]; then
 mkdir -p /etc/dnf/vars
 echo $basearch > /etc/dnf/vars/basearch
-echo $arch > /etc/dnf/vars/basearch
+echo $arch > /etc/dnf/vars/arch
 else
 echo $basearch > /etc/yum/vars/basearch
 echo $arch > /etc/yum/vars/arch



Thank you,

d.marlin


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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2016-11-14 17:26:49 +:
> On 2016-11-14 09:53:03 -0600 (-0600), Michał Jastrzębski wrote:
> [...]
> > We don't have any other project with multiple licenses in it? What
> > would LICENSE file in github show? Do we need to mention parts of
> > GPL there?
> 
> We have plenty (I expect it may even be a majority) of repos
> containing files under different licenses, though I'm not aware of
> examples of one of our repos containing files under a mix of GPLv3
> and Apache License v2.0.
> 
> A quick search for http://codesearch.openstack.org/?q=gpl=1 turns
> up the openstack/murano-apps repo which has content aggregated under
> a mix of Apache License v2.0, GPLv2 (inherited from Plone), GPLv3
> (from Clearwater), and GNU AGPLv3 (SugarCRM); it calls them out with
> separate LICENSE files in different subtrees. The openstack/vmtp
> repo has an aggregation of Apache License v2.0, BSD and GPLv2 files
> with some details in their README.rst explaining the situation. A
> number of Apache-licensed repos used to include a tools/rfc.sh
> script (copied from Horizon I think?) which claimed in its comment
> header to be distributed under GPLv3, though these seem to have been
> cleaned up in all non-retired repos more recently. The
> openstack/fuel-library repo has a dangerous-looking mix of Puppet
> modules under Apache License v2.0 and GPLv2 licenses, so probably
> not a shining example of how to go about this.
> 
> Hopefully that provides a diverse cross-section of examples.

If nothing else, it shines light on the fact that some project teams may
not be practicing license oversight as much as the rest of us would like
them to.

This is not surprising to me, but it might be worth adding to review
guidelines.

http://docs.openstack.org/infra/manual/developers.html#code-review

It's also entirely possible (shock!) that people haven't actually read
the CLA, by-laws, etc, and don't understand that they're not supposed
to mix these licenses together. Heck, even after this discussion, I'm
not really sure whether or not it's OK.

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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Michał Jastrzębski]

Sooowe do have a precedence (multiple of them in fact), just it
seems to be flying under the radar?

On 14 November 2016 at 11:26, Jeremy Stanley  wrote:
> On 2016-11-14 09:53:03 -0600 (-0600), Michał Jastrzębski wrote:
> [...]
>> We don't have any other project with multiple licenses in it? What
>> would LICENSE file in github show? Do we need to mention parts of
>> GPL there?
>
> We have plenty (I expect it may even be a majority) of repos
> containing files under different licenses, though I'm not aware of
> examples of one of our repos containing files under a mix of GPLv3
> and Apache License v2.0.
>
> A quick search for http://codesearch.openstack.org/?q=gpl=1 turns
> up the openstack/murano-apps repo which has content aggregated under
> a mix of Apache License v2.0, GPLv2 (inherited from Plone), GPLv3
> (from Clearwater), and GNU AGPLv3 (SugarCRM); it calls them out with
> separate LICENSE files in different subtrees. The openstack/vmtp
> repo has an aggregation of Apache License v2.0, BSD and GPLv2 files
> with some details in their README.rst explaining the situation. A
> number of Apache-licensed repos used to include a tools/rfc.sh
> script (copied from Horizon I think?) which claimed in its comment
> header to be distributed under GPLv3, though these seem to have been
> cleaned up in all non-retired repos more recently. The
> openstack/fuel-library repo has a dangerous-looking mix of Puppet
> modules under Apache License v2.0 and GPLv2 licenses, so probably
> not a shining example of how to go about this.
>
> Hopefully that provides a diverse cross-section of examples.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [api]

[Ed Leafe]

On Nov 14, 2016, at 6:04 AM, milanisko k  wrote:

> I'd like to ask about possible ``=in:``[1] operator negation implementation 
> Should the implementation be a negative field name such as 
> ``?state=in:a,b,c_state=in:x,y,z``?
> Or rather a negated operator: ``?state=in:a,b,c=not_in:x,y,z``?
> There already is the ``=neq:`` operator specified in the filtering spec[1], 
> so I guess ``=not_in:/=nin:/=out:`` might be more appropriate?

The latter looks better to me. I’d like to get feedback on the exact choice of 
``=not_in:/=nin:/=out:`` to recommend. Personally, I prefer ‘nin’, but I’ll 
defer to others on that.

-- Ed Leafe






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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Jeremy Stanley]

On 2016-11-14 09:53:03 -0600 (-0600), Michał Jastrzębski wrote:
[...]
> We don't have any other project with multiple licenses in it? What
> would LICENSE file in github show? Do we need to mention parts of
> GPL there?

We have plenty (I expect it may even be a majority) of repos
containing files under different licenses, though I'm not aware of
examples of one of our repos containing files under a mix of GPLv3
and Apache License v2.0.

A quick search for http://codesearch.openstack.org/?q=gpl=1 turns
up the openstack/murano-apps repo which has content aggregated under
a mix of Apache License v2.0, GPLv2 (inherited from Plone), GPLv3
(from Clearwater), and GNU AGPLv3 (SugarCRM); it calls them out with
separate LICENSE files in different subtrees. The openstack/vmtp
repo has an aggregation of Apache License v2.0, BSD and GPLv2 files
with some details in their README.rst explaining the situation. A
number of Apache-licensed repos used to include a tools/rfc.sh
script (copied from Horizon I think?) which claimed in its comment
header to be distributed under GPLv3, though these seem to have been
cleaned up in all non-retired repos more recently. The
openstack/fuel-library repo has a dangerous-looking mix of Puppet
modules under Apache License v2.0 and GPLv2 licenses, so probably
not a shining example of how to go about this.

Hopefully that provides a diverse cross-section of examples.
-- 
Jeremy Stanley


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

[openstack-dev] [new][security] syntribos 0.3.0 release

[no-reply]

We are stoked to announce the release of:

syntribos 0.3.0: API Security Scanner

Download the package from:

https://pypi.python.org/pypi/syntribos

Please report issues through launchpad:

https://bugs.launchpad.net/syntribos

For more details, please see below.

Changes in syntribos 0.1.2..0.3.0
-

a2f1d7c Fixing a bug due to getlogin() in syntribos
09f5a18 Updating readme
e409282 Updated from global requirements
4e174d5 Adding extension for common utility functions
55ef06d Added pause/resume feature
453110e Don't include openstack/common in flake8 exclude list
e7859d2 Updating readme with sheilds and update License
c59e0bd Adding unit tests
46d5ba4 Introduced payload and template downloading
de45ea2 Updated from global requirements
ee0dd4b OpenStack URI markup fixed
ee004cd Linting documentation
65aa87a Fixing ordering of Runner.run and version bump
18781c3 Add additional runner and env utils tests
dabac29 Creates syntribos 'init' command
8faed09 Fixing unicode error
b18624f Fixing doc nits
a900b97 Updating the docs and fixing some nits
34091d3 Changing payloads_dir to payloads
42328a1 Fixing a nit in contributing guide
8bbe40f Updating the Project Structure documentation
b88f84b Updating setup.cfg for PyPI release
8a74e56 Fixup 'payloads' in docs, add #! to readme script
0824fdd Updating syntribos documentation
d6c6ea7 Updating documentation
b7b925c Loading payload from remote URI
3ab0240 Updating logging information for Syntribos
55e9212 Removing reference to opencafe in the contributing doc
d965f9e Changing the author information and the home page
0e116be Documentation updates and styling changes
c501886 Updated from global requirements
b80f2ca Fix BaseTestCase bug
6cf5ab2 Adding Cinder extension support to templates
3901c85 Updated from global requirements
a82694d Modified dry_run to run debug test
8f8e932 Updating the README.rst file
5911450 Adding python 3 compatibility and some minor styling changes
7788966 Minor modifications to the doc string and a few styling changes
7570024 Remove white space between print and ()
3f5ac5a Updated from global requirements
c7c9fbb Added nova extension client
d32794e Updated from global requirements
426ad1f Updated from global requirements
5ee59a6 Adding extension for cinder client
3d66477 Adding swift request templates
9821c2e Adding request templates for cinder(block storage)
ee3b442 Adding Cinder templates for Syntribos testing
8a61f36 Adding Cinder templates
dbeb19a Added cinder and swift templates
8329981 Updated from global requirements
0d1d7b4 TrivialFix: Remove default=None when set value in Config
51fb2f7 Added nova templates (hypervisors to external events)
2fee9c2 Adding Template files for the compute service
0622b70 Updated from global requirements
358b6e4 Adding nova templates for Syntribos
28937c8 Adding Nova template files
4809460 A spelling mistake needs to be fixed
77f06d5 Adding unittests for glance client
b4e0f68 Adding unittest for neutron client extension
3d95b20 Minor modifications to the neutron templates
940906a Updated from global requirements
8d0d6f7 A minor naming change for a neutron extension
50a4a77 Glance template tweaks
d220661 Simplify Glance and Neutron extension clients
d63c42d Fixing up SSL test
5ba09b9 Changing get_token to get_scoped_token for neutron templates
183667e An extenstion to retrieve network data from an openstack cloud
baa8ac2 Adding Glance extension support to templates
9ebb4f4 Extensions for glance resources
cd0691d Added glance templates
48280a8 Adding glance templates
7c388f1 Glance image tags and image schema templates
9810a73 Glance Images Templates
69c06f1 Minor changes to memoize
b49a28a Upgrading memoize to memoize functions with same kwargs as well
e1644ce Fixing some documentation nits
9e7b785 Adding neutron templates for Syntribos
e438463 Refactoring debug_logger
8827cf3 Adding templates for neutron
2ae5d7b Added neutron templates
96cb4c2 Neutron LBaaS and FWaaS templates
a81f052 Add man page for syntribos command
d660e66 Fixing tiny nit in keystone templates
952dcc7 Unit tests for the identity client
154fb05 Adding config fixture
1c0d547 Fix bug with identity client memoization
efdc668 Cleanup some nits in the README
747d0bd Updating docs to reflect changes in README
1740eda Adding capability to retrieve scoped tokens
faffc44 Removing overlapping payload/failure key
8658ec3 A nit in seperator
de0bbf3 Fixing bug in logger
85fe413 Fixed bug where CLI failure counts were cumulutive
61b144f Fixed runner time log
f8a9075 Minor nit in progress display
38a6dc1 Modifying log file path
af7d10c Adds relative paths for templates
adca69a Revamped results schema
8249287 patch to sanitize debug log
8bd026a Deleting unused data files
57e6a82 Buffer Overflow data file dependency is removed
4876101 Added config file improvements
e442dc8 changes to runner and result
c6056e2 Minor fixup to readme
c4cbbe8 Refresh readme
0bfa537 Standardizing the way we diff signals
c3be7d5 Adding 

[openstack-dev] [new][horizon] XStatic-bootswatch 3.3.7.0 release

[no-reply]

We are psyched to announce the release of:

XStatic-bootswatch 3.3.7.0: bootswatch 3.3.7 (XStatic packaging
standard)

This is the first release of XStatic-bootswatch.

Download the package from:

https://pypi.python.org/pypi/XStatic-bootswatch

For more details, please see below.

Changes in XStatic-bootswatch 4e38e9e22901298acc79724fb9c5d1b3d95cf06f..3.3.7.0
---

49c0d56 Update XStatic-bootswatch to 3.3.7.0
e4f6678 Update to version 3.3.6
2c0a7a1 Deprecated tox -downloadcache option removed
481cf09 Update .gitreview for new namespace
946609f Update Bootswatch to 3.3.5-3
c17e28d Remove unneeded extra space
499ea03 xstatic-package for Bootswatch Bootstrap Themes






__
OpenStack Development Mailing List (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] [new][horizon] XStatic-Font-Awesome 4.7.0.0 release

[no-reply]

We are ecstatic to announce the release of:

XStatic-Font-Awesome 4.7.0.0: Font-Awesome 4.7.0 (XStatic packaging
standard)

Download the package from:

https://pypi.python.org/pypi/XStatic-Font-Awesome

For more details, please see below.

Changes in XStatic-Font-Awesome 4.3.0.0..4.7.0.0


8a671c3 Update XStatic-font-awesome to 4.7.0.0
3419b4f Update FontAwesome to 4.5.0 from 4.3.0
40f0712 Deprecated tox -downloadcache option removed
fcd2d1b Update .gitreview for new namespace
a8e3c71 Add tox.ini to enable publish/tarball job


Diffstat (except docs and test files)
-

.gitreview |2 +-
MANIFEST.in|4 +-
setup.cfg  |   20 +
setup.py   |8 +-
tox.ini|8 +
xstatic/pkg/font_awesome/__init__.py   |8 +-
xstatic/pkg/font_awesome/data/css/font-awesome.css |  558 +++-
.../pkg/font_awesome/data/css/font-awesome.css.map |7 -
.../pkg/font_awesome/data/css/font-awesome.min.css |4 +-
.../pkg/font_awesome/data/fonts/FontAwesome.otf|  Bin 93888 -> 134808 bytes
.../data/fonts/fontawesome-webfont.eot |  Bin 60767 -> 165742 bytes
.../data/fonts/fontawesome-webfont.svg | 3230 
.../data/fonts/fontawesome-webfont.ttf |  Bin 122092 -> 165548 bytes
.../data/fonts/fontawesome-webfont.woff|  Bin 71508 -> 98024 bytes
.../data/fonts/fontawesome-webfont.woff2   |  Bin 56780 -> 77160 bytes
.../font_awesome/data/less/bordered-pulled.less|9 +
xstatic/pkg/font_awesome/data/less/core.less   |3 +-
.../pkg/font_awesome/data/less/font-awesome.less   |3 +-
xstatic/pkg/font_awesome/data/less/icons.less  |  197 +-
xstatic/pkg/font_awesome/data/less/mixins.less |   41 +-
xstatic/pkg/font_awesome/data/less/path.less   |2 +-
.../pkg/font_awesome/data/less/screen-reader.less  |5 +
xstatic/pkg/font_awesome/data/less/variables.less  |  202 +-
.../font_awesome/data/scss/_bordered-pulled.scss   |9 +
xstatic/pkg/font_awesome/data/scss/_core.scss  |3 +-
xstatic/pkg/font_awesome/data/scss/_icons.scss |  197 +-
xstatic/pkg/font_awesome/data/scss/_mixins.scss|   41 +-
.../pkg/font_awesome/data/scss/_screen-reader.scss |5 +
xstatic/pkg/font_awesome/data/scss/_variables.scss |  202 +-
.../pkg/font_awesome/data/scss/font-awesome.scss   |3 +-
30 files changed, 4149 insertions(+), 622 deletions(-)




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

[openstack-dev] [glance] Flakey functional test (Was: [Openstack-stable-maint] Stable check of openstack/glance failed)

[Ian Cordasco]

-Original Message-
From: A mailing list for the OpenStack Stable Branch test reports.

Reply: openstack-dev@lists.openstack.org 
Date: November 12, 2016 at 00:11:31
To: openstack-stable-ma...@lists.openstack.org

Subject:  [Openstack-stable-maint] Stable check of openstack/glance failed

> Build failed.
>
> - periodic-glance-docs-liberty 
> http://logs.openstack.org/periodic-stable/periodic-glance-docs-liberty/ae58dd7/
> : SUCCESS in 2m 08s
> - periodic-glance-python27-db-liberty 
> http://logs.openstack.org/periodic-stable/periodic-glance-python27-db-liberty/f196df2/
> : SUCCESS in 6m 05s
> - periodic-glance-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-glance-docs-mitaka/bb89d74/
> : SUCCESS in 4m 32s
> - periodic-glance-python27-db-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-glance-python27-db-mitaka/758e639/
> : SUCCESS in 6m 28s
> - periodic-glance-docs-newton 
> http://logs.openstack.org/periodic-stable/periodic-glance-docs-newton/915cb75/
> : SUCCESS in 4m 35s
> - periodic-glance-python27-db-newton 
> http://logs.openstack.org/periodic-stable/periodic-glance-python27-db-newton/95226d2/
> : FAILURE in 7m 20s

Hi Glance team members,

Over the weekend one of our stable periodic jobs failed. It failed on
a test (glance.tests.functional.test_reload.TestReload.test_reload)
that I've seen fail a couple times previously. I've created a bug for
this: https://bugs.launchpad.net/glance/+bug/1641670 And I'm hoping
someone will be able to reproduce it and fix it.

I suspect, this is a matter of resource contention in the donated VMs
that our CI uses, but I can't be certain.

The stable team would greatly appreciate help diagnosing and fixing this issue.

Cheers,
--
Ian Cordasco

__
OpenStack Development Mailing List (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] [new][horizon] XStatic-roboto-fontface 0.5.0.0 release

[no-reply]

We are glad to announce the release of:

XStatic-roboto-fontface 0.5.0.0: roboto-fontface 0.5.0 (XStatic
packaging standard)

This is the first release of XStatic-roboto-fontface.

Download the package from:

https://pypi.python.org/pypi/XStatic-roboto-fontface

For more details, please see below.

Changes in XStatic-roboto-fontface 
54ea281bd386ef7f1f7b0bdd001ac8afd3a8d882..0.5.0.0


480b520 Update XStatic-roboto to 0.5.0.0
a4ec81c Add basic tox.ini file
f9d3fab Update .gitreview for new namespace
758dd13 Remove unneeded extra space
c75b5d9 xstatic-package for Roboto Font Face






__
OpenStack Development Mailing List (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] [new][openstackclient] os-client-config 1.23.0 release (ocata)

[no-reply]

We are ecstatic to announce the release of:

os-client-config 1.23.0: OpenStack Client Configuation Library

This release is part of the ocata release series.

The source is available from:

http://git.openstack.org/cgit/openstack/os-client-config

Download the package from:

https://pypi.python.org/pypi/os-client-config

Please report issues through launchpad:

http://bugs.launchpad.net/os-client-config

For more details, please see below.

Changes in os-client-config 1.22.0..1.23.0
--

1f9e2cd Remove validate_auth_ksc
9f47acc Add fuga.io to vendors
b5d65b7 Support token_endpoint as an auth_type
3f525e0 Add support for volumev3 service type
86ade8f Normalize cloud config before osc-lib call
1ac6766 Fix a bunch of tests
422ad9c Clarify how to set SSL settings
47068d0 Update ECS image_api_version to 1


Diffstat (except docs and test files)
-

README.rst| 13 
os_client_config/cloud_config.py  |  9 ++-
os_client_config/config.py| 88 ---
os_client_config/vendors/entercloudsuite.json |  1 +
os_client_config/vendors/fuga.json| 15 +
10 files changed, 138 insertions(+), 76 deletions(-)




__
OpenStack Development Mailing 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] Problem with Quota and servers spawned in groups

[Chris Friesen]

On 11/11/2016 07:07 AM, Sławek Kapłoński wrote:

Hello,

Can maybe someone (from core team) take a look on that? Thx in advance :)



As Melanie Witt mentioned on your bug report, there are a number of issues 
around multi-boot.   (I reported https://bugs.launchpad.net/nova/+bug/1458122 
last year, for example.)


Getting rid of multi-boot has been proposed a number of times but was shot down 
on efficiency arguments.


In order to improve this someone needs to write up a spec to make the whole 
multi-boot story coherent.  At a minimum this would need to address:


1) the quota issue you raised
2) the partial completion issue I raised
3) returning the uuids of all instances booted as a result of the multiboot API 
call

Since it means a spec, probably nothing will happen in Ocata...we could maybe 
see about Pike.


Chris

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

Re: [openstack-dev] [glance] priorities for O-1

[Ian Cordasco]

-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: November 10, 2016 at 08:32:51
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [glance] priorities for O-1

> Hello Glancers,
>
> O-1 is around the corner (i.e., next week). The priority for Glance is
> Community Images.
>
> Please review the following patches:
>
> https://review.openstack.org/#/c/369110/
> https://review.openstack.org/#/c/387660/
> https://review.openstack.org/#/c/391968/

Glance reviewers,

Please prioritize reviewing the above patches. These are the highest
priority items for Ocata-1 and need to merge so we can stabilize them
throughout the rest of this very short cycle.

I will be proposing a review to openstack/releases to tag Ocata-1. For
now, I will block the workflow, but on Thursday, I will update it and
encourage the Release team to move forward with it regardless of
whether these have merged or not. While these are a priority, as
Release Czar I cannot force you to review them but I must move forward
with our release plans.

Cheers,
--
Ian Cordasco

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

Re: [openstack-dev] [ironic] Removing agent vendor passthru and unsupported drivers

[Mathieu Mitchell]

Hi Pavlo,

See my reply below.

On 2016-11-14 7:50 AM, Pavlo Shchelokovskyy wrote:

Hi Ironicers,

currently I'm busy with removing the lookup/heartbeats "as vendor passthru"
from Ironic which we slated for removal in Ocata, and have the following
question.

Removing the old agent vendor passthru requires changes to some unsupported
drivers whose copies are already in ironic-staging-drivers. The drivers in
question are WoL, iBoot and especially AMT (which uses a custom
not-so-vendor passthru).


The "follows-standard-deprecation" policy states the following 
"Features, APIs or configuration options are marked deprecated in the 
code. Appropriate warnings will be sent to the end user, operator or 
library user. **Code will be frozen and only receive minimal maintenance 
(just so that it continues to work as-is).**" [0] (emphasis mine). My 
understanding is that your changes would fall into the "just so that it 
continues to work as-is" clause.




AFAIU according to our third-party drivers policy, those unsupported
drivers have to be removed from Ironic tree anyway (as there is no plan to
test them on third-party CI AFAIK) and this looks like a perfect time to do
it.

So ideally I'd like to fix those in ironic-staging-drivers and then remove
them from Ironic tree via a depends-on patch.

What do you think on such plan?


The drivers were marked for removal in Ocata [1], so you can already 
remove them from the tree. A simple but relevant thing I note is that it 
would be preferable, from my point of view, to remove them all in a 
single commit.


Finally, I would add that functional CI coverage for the SNMP driver is 
well under way [2]. We are currently doing the work to keep the SNMP 
driver in-tree (what we are doing is similar to VirtualBMC and the IPMI 
driver). Going ahead with a single commit to remove all the drivers 
would impact our current work. I would therefore suggest doing the 
required "vendor passthru" changes to the different drivers and 
post-pone the commit to delete all unsupported drivers.


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

[1] http://docs.openstack.org/releasenotes/ironic/current-series.html#id5
[2] https://review.openstack.org/#/q/status:open+topic:bug/1597793

Thank you,
Mathieu Mitchell
Internap



Cheers,
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] [glance] spec proposal freeze

[Ian Cordasco]

-Original Message-
From: Ian Cordasco 
Reply: Ian Cordasco 
Date: November 10, 2016 at 09:52:58
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [glance] spec proposal freeze

> -Original Message-
> From: Brian Rosmaita  
> Reply: OpenStack Development Mailing List (not for usage questions)  
> Date: November 9, 2016 at 16:10:05
> To: OpenStack Development Mailing List (not for usage questions)  
> Subject: [openstack-dev] [glance] spec proposal freeze
> > The purpose of the proposal freeze is to allow sufficient time for the
> > specs to be reviewed, revised, and merged before the Spec Freeze on Friday
> > 25 November at 23:59 UTC.
> >
> > cheers,
> > brian
>  
> One last reminder to everyone that the proposal deadline is now not far off.

Glance cores and drivers,

Please be sure to review the proposed specs before Friday 25 November 2016, 
23:59 UTC.

Cheers,
--  
Ian Cordasco


__
OpenStack Development Mailing 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] [nettworking-ovn [patch-update b8af082

[Murali R]

Thanks Gary.

On Sun, Nov 13, 2016 at 2:33 AM, Gary Kotton  wrote:

> Hi,
>
> No, you do not need to do a DB sync. This is just updating a constants –
> that is the same constant definition was moved from one please to another.
> So it should be backwards compatibale.
>
> Thanks
>
> Gary
>
>
>
> *From: *Murali R 
> *Reply-To: *OpenStack List 
> *Date: *Sunday, November 13, 2016 at 9:01 AM
> *To: *OpenStack List 
> *Subject: *[openstack-dev] [nettworking-ovn [patch-update b8af082
>
>
>
> I would like to update this patch on a standard deployment of Newton.
> After applying patch (copying over diffs) are there any steps needed for db
> sync? There are a number of changes in ovn_db_sync.py
>
>
>
> https://github.com/openstack/networking-ovn/commit/
> b8af082e326d1294ec3110a1d4ac266da84868b8
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Zane Bitter]

On 13/11/16 11:44, Jeremy Stanley wrote:

On 2016-11-12 17:44:42 -0800 (-0800), Clint Byrum wrote:

https://www.apache.org/licenses/GPL-compatibility.html

"This licensing incompatibility applies only when some Apache project
software becomes a derivative work of some GPLv3 software, because then
the Apache software would have to be distributed under GPLv3. This would
be incompatible with ASF's requirement that all Apache software must be
distributed under the Apache License 2.0.

We avoid GPLv3 software because merely linking to it is considered by
the GPLv3 authors to create a derivative work. We want to honor their
license. Unless GPLv3 licensors relax this interpretation of their own
license regarding linking, our licensing philosophies are fundamentally
incompatible. This is an identical issue for both GPLv2 and GPLv3.

Despite our best efforts, the FSF has never considered the Apache
License to be compatible with GPL version 2, citing the patent
termination and indemnification provisions as restrictions not present
in the older GPL license. The Apache Software Foundation believes that
you should always try to obey the constraints expressed by the copyright
holder when redistributing their work."

So, no, I don't believe that they're compatible and I don't believe this
could even be rewritten to be ASL 2.0.

Ansible plugins need to be GPLv3. Period.


Fair enough. This seems to be a point of contention (whether using a
library inherently makes the software written to use it a derivative
work of that library, or merely requires the two when distributed to
be licensed compatibly):

http://www.rosenlaw.com/lj19.htm
https://lwn.net/Articles/548216/


Sure, and it's even less clear with a language like Python, where you're 
not distributing a binary that is derived from the source code of the 
GPL component.



The ASF position seems to be generally grounded in the FSF's
interpretation,


I think the ASF's position is grounded in not wanting to score a 
spectacular own goal for FOSS by getting into an unnecessary licensing 
dispute with another open source project :)



and the opinions of those writing licenses aren't
necessarily always the opinions of those using them. We'd probably
be better off getting an opinion in writing from the Ansible devs on
whether they consider Ansible Python modules to cause the plug-ins
importing them to necessarily become derivative works.


It only takes one copyright holder to disagree before you find yourself 
trying to explain to a jury how this "derived class" isn't actually a 
"derivative work". That's worth avoiding even when you're correct.


So unless there was an up-front interpretation, preferably in the 
license file itself, I think it's perfectly reasonable that we're taking 
a conservative approach.



Anyway, in the case in question it's irrelevant since the planned
plug-in will be directly derivative of the source code of an
existing GPLv3-licensed plug-in, so it remains academic for now
unless they've already officially answered that question elsewhere.


I think it just has to be an exception and stored in a separate
repo.


This is a leap I'm still unclear on. Is this separation for logistic
reasons? There's nothing I've seen which says every file in a Git
repo needs to be under even compatible licenses much less the same
license, nor does separating files into different repos magically
solve legal problems around license compatibility. It's been
suggested that our ICLA makes this a problem, but we don't say that
the ICLA covers every file in any particular Git repo (and in fact
we don't mention in the ICLA what software exactly is covered by
it... repos marked as deliverables of official teams recognized by
the TC? it would be nice to get that clarified).


Agreed, it hasn't been as clear as it probably should be. It was 
certainly not our position in the past that non-official repos are not 
covered by the CLA, because I believe we have relied on the CLA when 
incubating previously non-official projects (IIRC having all past 
contributors sign the CLA was one of the checklist requirements).


I think the DCO process makes things much clearer though. It's quite 
easy to understand that contributions to an ASL2-licensed repo are ASL2 
and contributions to a GPL-licensed repo are GPL.



If Kolla uses Ansible through subprocess/CLI integration which we
consider to not cause Kolla to be derivative, then does that
situation change if we put parts of Ansible in a Kolla repo and mark
those files as being distributed under GPLv3? What then makes
including this additional Ansible plug-in in a Kolla repo any
different from that situation? And how would putting it in a
separate repo instead change the licensing situation for it?


1) It can be in a non-official repo without making all of Kolla 
non-official; and
2) a whole repo that is licensed as GPL leaves much less room for 
confusion than a repo that contains a mixture of ASL2 and GPL code (in 
terms of how 

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Thierry Carrez]

Michał Jastrzębski wrote:
> Logistically it would be best to make this one file GPLv3. No other
> files would need to be GPLv3 in Kolla as this is only one that will be
> derivative, rest of Kolla will be safe because of subprocess
> separation. Who would be able to say whether or not it's possible to
> put single GPLv3 file into otherwise ASL repository? We don't have any
> other project with multiple licenses in it? What would LICENSE file in
> github show? Do we need to mention parts of GPL there?

You can raise it on the legal-discuss mailing-list (or I can have it
formally looked up by the Foundation legal counsel) but I'm 99% sure the
answer will be that we can't. All OpenStack software must be licensed
under a license supported by the Contributor License Agreement (CLA)
which allows redistribution by the OpenStack Foundation under ASLv2
(currently only the MIT and both forms of the BSD license meet this
requirement).

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

[Michał Jastrzębski]

Logistically it would be best to make this one file GPLv3. No other
files would need to be GPLv3 in Kolla as this is only one that will be
derivative, rest of Kolla will be safe because of subprocess
separation. Who would be able to say whether or not it's possible to
put single GPLv3 file into otherwise ASL repository? We don't have any
other project with multiple licenses in it? What would LICENSE file in
github show? Do we need to mention parts of GPL there?

On 13 November 2016 at 10:44, Jeremy Stanley  wrote:
> On 2016-11-12 17:44:42 -0800 (-0800), Clint Byrum wrote:
>> https://www.apache.org/licenses/GPL-compatibility.html
>>
>> "This licensing incompatibility applies only when some Apache project
>> software becomes a derivative work of some GPLv3 software, because then
>> the Apache software would have to be distributed under GPLv3. This would
>> be incompatible with ASF's requirement that all Apache software must be
>> distributed under the Apache License 2.0.
>>
>> We avoid GPLv3 software because merely linking to it is considered by
>> the GPLv3 authors to create a derivative work. We want to honor their
>> license. Unless GPLv3 licensors relax this interpretation of their own
>> license regarding linking, our licensing philosophies are fundamentally
>> incompatible. This is an identical issue for both GPLv2 and GPLv3.
>>
>> Despite our best efforts, the FSF has never considered the Apache
>> License to be compatible with GPL version 2, citing the patent
>> termination and indemnification provisions as restrictions not present
>> in the older GPL license. The Apache Software Foundation believes that
>> you should always try to obey the constraints expressed by the copyright
>> holder when redistributing their work."
>>
>> So, no, I don't believe that they're compatible and I don't believe this
>> could even be rewritten to be ASL 2.0.
>>
>> Ansible plugins need to be GPLv3. Period.
>
> Fair enough. This seems to be a point of contention (whether using a
> library inherently makes the software written to use it a derivative
> work of that library, or merely requires the two when distributed to
> be licensed compatibly):
>
> http://www.rosenlaw.com/lj19.htm
> https://lwn.net/Articles/548216/
>
> The ASF position seems to be generally grounded in the FSF's
> interpretation, and the opinions of those writing licenses aren't
> necessarily always the opinions of those using them. We'd probably
> be better off getting an opinion in writing from the Ansible devs on
> whether they consider Ansible Python modules to cause the plug-ins
> importing them to necessarily become derivative works.
>
> Anyway, in the case in question it's irrelevant since the planned
> plug-in will be directly derivative of the source code of an
> existing GPLv3-licensed plug-in, so it remains academic for now
> unless they've already officially answered that question elsewhere.
>
>> I think it just has to be an exception and stored in a separate
>> repo.
>
> This is a leap I'm still unclear on. Is this separation for logistic
> reasons? There's nothing I've seen which says every file in a Git
> repo needs to be under even compatible licenses much less the same
> license, nor does separating files into different repos magically
> solve legal problems around license compatibility. It's been
> suggested that our ICLA makes this a problem, but we don't say that
> the ICLA covers every file in any particular Git repo (and in fact
> we don't mention in the ICLA what software exactly is covered by
> it... repos marked as deliverables of official teams recognized by
> the TC? it would be nice to get that clarified).
>
> If Kolla uses Ansible through subprocess/CLI integration which we
> consider to not cause Kolla to be derivative, then does that
> situation change if we put parts of Ansible in a Kolla repo and mark
> those files as being distributed under GPLv3? What then makes
> including this additional Ansible plug-in in a Kolla repo any
> different from that situation? And how would putting it in a
> separate repo instead change the licensing situation for it?
>
> I'm all for the Kolla devs deciding they don't want this file in the
> same repo as Kolla, but if we're going to say that there are legal
> reasons forcing their hand I'd like to see those reasons enumerated.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] New Core Reviewers

[Grant, Jaycen V]

Thank you all for your support.  I look forward to being able to support the 
Magnum community in this new role.

Jaycen

-Original Message-
From: Yatin Karel [mailto:yatin.ka...@nectechnologies.in] 
Sent: Sunday, November 13, 2016 11:04 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] New Core Reviewers

Hi All,

Thanks all for your votes and support for this new Role.

It is an honour to work with all of you and will continue my participation in 
the community.

Regards,
Yatin


From: Adrian Otto [adrian.o...@rackspace.com]
Sent: Monday, November 14, 2016 9:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] New Core Reviewers

Jaycen and Yatin,

You have each been added as new core reviewers. Congratulations to you both, 
and thanks for stepping up to take on this new role!

Cheers,

Adrian

> On Nov 7, 2016, at 11:06 AM, Adrian Otto  wrote:
>
> Magnum Core Team,
>
> I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum Core 
> Reviewers. Please respond with your votes.
>
> Thanks,
>
> Adrian Otto


__
OpenStack Development Mailing List (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] [OpenStack-Infra] [infra][neutron] Intel NFV CI voting permission in Neutron

[Jeremy Stanley]

On 2016-11-14 10:44:42 + (+), Znoinski, Waldemar wrote:
> I would like to acquire voting (+/-1 Verified) permission for our
> Intel NFV CI.
[...]

The requested permission is configured by addition to
https://review.openstack.org/#/admin/groups/neutron-ci which is
controlled by the members of the
https://review.openstack.org/#/admin/groups/neutron-release group.
The Infra team tries not to be involved in these decisions and
instead prefers to leave them up to the project team(s) involved.

> This e-mail and any attachments may contain confidential material
> for the sole use of the intended recipient(s). Any review or
> distribution by others is strictly prohibited.
[...]

This seems wholly inappropriate for a public mailing list. I
strongly recommend not sending messages to our mailing lists in
which you strictly prohibit review or distribution by others, as it
is guaranteed to happen and we cannot prevent that (nor would we
want to).
-- 
Jeremy Stanley

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

[openstack-dev] [kolla] repo split underway

[Steven Dake (stdake)]

Hey folks,

Thanks to the efforts of the openstyack-infra and release teams in coaching me 
through how to do the job properly, the repo split is ready to go (requires a 
couple +1’s from inc0 as he is the PTL of our merry band).

What this means is some patches that are merging now may have to be remerged if 
they touch ansible/* )since I had to take a snapshot of the kolla repository 
Saturday morning to remove all the tags/branches.  Boy that was somewhat 
painful ;(  Anyway, apologies for the remerge requirements.  I suspect inc0 
will send out an announcement when the repository split is finished.

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] [ironic] When should a project be under Ironic's governance?

[Jim Rollenhagen]

On Thu, Nov 10, 2016 at 11:21 AM,   wrote:
> Second try
>
> -Original Message-
> From: Kanevsky, Arkady
> Sent: Thursday, November 10, 2016 10:08 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: RE: [openstack-dev] [ironic] When should a project be under Ironic's 
> governance?
>
> Fully agree.
> How do we propose to handle dependency of Ironic  version on specific version 
> of a driver?
> Clearly distros can do it but we will not have a version for user of upstream 
> to use without building it themselves.
> I am only referring to ironic drivers that do pass CI voting that user expect 
> availability of.

I'm not quite sure what you mean here.

For optional libraries (like proliantutils), we use a
driver-requirements.txt file
that is versioned the same as ironic, which both packagers and users can use
to determine what version of a library is required. Libraries may also carry
stable branches like ironic, whether they are inside or outside of
ironic governance.

For in-tree drivers, well, those are versioned the same as ironic.

For out-of-tree drivers, it's the same as optional libraries, except
that we don't
have a requirements.txt-style file. Folks maintaining out-of-tree
drivers will need
to document what version of their driver works with what version of ironic. Of
course, these drivers can also carry stable branches.

Does that help?

// jim

> Thanks,
> Arkady
>
> -Original Message-
> From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
> Sent: Wednesday, November 02, 2016 9:37 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [ironic] When should a project be under Ironic's 
> governance?
>
> On Mon, Oct 17, 2016 at 4:27 PM, Michael Turek  
> wrote:
>> Hello ironic!
>>
>> At today's IRC meeting, the questions "what should and should not be a
>> project be under Ironic's governance" and "what does it mean to be
>> under Ironic's governance" were raised. Log here:
>>
>> http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-
>> 17.00.log.html#l-176
>>
>> See http://governance.openstack.org/reference/projects/ironic.html for
>> a list of projects currently under Ironic's governance.
>>
>> Is it as simple as "any project that aides in openstack baremetal
>> deployment should be under Ironic's governance"? This is probably too
>> general (nova arguably fits here) but it might be a good starting point.
>>
>> Another angle to look at might be that a project belongs under the
>> Ironic governance when both Ironic (the main services) and the
>> candidate subproject would benefit from being under the same
>> governance. A hypothetical example of this is when Ironic and the candidate 
>> project need to release together.
>>
>> Just some initial thoughts to get the ball rolling. What does everyone
>> else think?
>
> We discussed this during our contributor's meetup at the summit, and came to 
> consensus in the room, that in order for a repository to be under ironic's 
> governance:
>
> * it must roughly fall within the TC's rules for a new project:
>   http://governance.openstack.org/reference/new-projects-requirements.html
> * it must not be intended for use with only a single vendor's hardware (e.g. 
> a library
>   to handle iLO is not okay, a library to handle IPMI is okay).
> * it must align with ironic's mission statement: "To produce an OpenStack 
> service
>   and associated libraries capable of managing and provisioning physical 
> machines,
>   and to do this in a security-aware and fault-tolerant manner."
> * lack of contributor diversity is a chicken-egg problem, and as such a 
> repository
>   where only a single company is contributing is okay.
>
> I've proposed this as a docs patch: https://review.openstack.org/392685
>
> We decided we should get consensus from all cores on that patch - meaning 80% 
> or more agree, and any that disagree will still agree to live by the 
> decision. So, cores, please chime in on gerrit. :)
>
> Once that patch lands, I'll submit a patch to openstack/governance to shuffle 
> projects around where they do or don't fit.
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage 

[openstack-dev] [infra][gate][all] Changes to the devstack-gate feature matrix

[Sean M. Collins]

I have been working on a patch to devstack-gate[1], to implement a long
standing TODO, where the feature grid will be used to determine the
MY_ENABLED_SERVICES that are set[2].

Prior to this patch, there was a lot of manipulation being done to 
MY_ENABLED_SERVICES based on environment variables, and a lot of
conditional checks.

If your job configuration uses the OVERRIDE_ENABLED_SERVICES environment
variable, you are not affected. However, you may wish to examine this
patchset, since it is supposed to make things easier to maintain, going
forward.

The motivation for this patch is to solve the issue of setting the
services that would run on the primary node and the subnode (when
running Grenade jobs), without creating more logic checks in Bash. For
projects like Neutron[3], there is work that needs to be done to move
some services from the primary node (where they are currently upgraded)
to the subnode, to match how they will most likely be upgraded in a
production environment, where the control plane is upgraded first and
data plane components are upgraded later.

Introducing roles to devstack-gate in the feature matrix allows us to
define roles, and also set the enabled services, based on the role, more
easily. For example, this patch will make the movement of certain Neutron
agents (L3 agent, dhcp, metadata, etc) from the primary node over to
the subnode when running a Grenade test, easier.

Please take a look at the patch, a lot of work was done to ensure that
the emitted services when running test-matrix.py matches the logic that
was originally baked directly into devstack-gate, but more eyes on it is
always nice.


[1]: https://review.openstack.org/386072
[2]: https://review.openstack.org/#/c/386072/16/devstack-vm-gate.sh
[3]: https://etherpad.openstack.org/p/neutron-multinode-jobs-newton

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] git review command authentication failed

[Andreas Jaeger]

On 2016-11-14 14:45, Raman Gupta wrote:
> Hello,
> 
> Link to Error: http://paste.openstack.org/show/589125/

This error can come from a wrong setup, for example when your gerrit
preferred e-mail address does not match a primary
e-mail address for a foundation individual member account.

Please follow completely all steps - in order - at:
http://docs.openstack.org/infra/manual/developers.html#account-setup

If you still get that, see https://ask.openstack.org/question/56720 for
additional troubleshooting tips.

Last resort: Ask on #openstack-infra IRC channel,

Andreas

> Regards,
> Raman Gupta
> 
> On Mon, Nov 14, 2016 at 7:03 PM, Amrith Kumar  > wrote:
> 
> Hi Raman, welcome.
> 
> __ __
> 
> It would help immensely to look into this if you shared the exact
> error message(s) that you received.
> 
> __ __
> 
> I suggest you copy and paste the error into something like
> gist.github.org  or paste.openstack.org
>  and share a link to that buffer in
> email. Please make sure you sanitize it and remove your password and
> stuff like that.
> 
> __ __
> 
> Thanks,
> 
> __ __
> 
> -amrith
> 
> __ __
> 
> *From:*Raman Gupta [mailto:raman.op...@gmail.com
> ]
> *Sent:* Monday, November 14, 2016 8:27 AM
> *To:* openstack-dev@lists.openstack.org
> 
> *Subject:* Re: [openstack-dev] git review command authentication
> failed 
> 
> __ __
> 
> I apologise for this email here. II should have mailed it in general
> list.
> 
> __ __
> 
> Regards,
> 
> Raman Gupta
> 
> __ __
> 
> On Mon, Nov 14, 2016 at 6:47 PM, Raman Gupta  > wrote:
> 
> Hello,
> 
> __ __
> 
> I am trying to submit my first change set. I have setup my
> launchpad account and then signed
> in https://review.openstack.org/
> . In the setting column (HTTP
> Password) of https://review.openstack.org/
> , I got a username and generated
> password. 
> 
> __ __
> 
> I am using the above username and password in the prompt to
> successfully complete git review command which results in
> authentication failure.
> 
> __ __
> 
> Where am I doing the mistake?
> 
> __ __
> 
> Regards,
> 
> Raman Gupta
> 
> __ __
> 
> 
> __
> OpenStack Development Mailing List (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
> 


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


__
OpenStack Development Mailing 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] git review command authentication failed

[Raman Gupta]

Hello,

Link to Error: http://paste.openstack.org/show/589125/

Regards,
Raman Gupta

On Mon, Nov 14, 2016 at 7:03 PM, Amrith Kumar  wrote:

> Hi Raman, welcome.
>
>
>
> It would help immensely to look into this if you shared the exact error
> message(s) that you received.
>
>
>
> I suggest you copy and paste the error into something like gist.github.org
> or paste.openstack.org and share a link to that buffer in email. Please
> make sure you sanitize it and remove your password and stuff like that.
>
>
>
> Thanks,
>
>
>
> -amrith
>
>
>
> *From:* Raman Gupta [mailto:raman.op...@gmail.com]
> *Sent:* Monday, November 14, 2016 8:27 AM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] git review command authentication failed
> 
>
>
>
> I apologise for this email here. II should have mailed it in general list.
>
>
>
> Regards,
>
> Raman Gupta
>
>
>
> On Mon, Nov 14, 2016 at 6:47 PM, Raman Gupta 
> wrote:
>
> Hello,
>
>
>
> I am trying to submit my first change set. I have setup my launchpad
> account and then signed in https://review.openstack.org/. In the setting
> column (HTTP Password) of https://review.openstack.org/, I got a username
> and generated password.
>
>
>
> I am using the above username and password in the prompt to successfully
> complete git review command which results in authentication failure.
>
>
>
> Where am I doing the mistake?
>
>
>
> Regards,
>
> Raman Gupta
>
>
>
> __
> OpenStack Development Mailing List (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] git review command authentication failed

[Amrith Kumar]

Hi Raman, welcome.



It would help immensely to look into this if you shared the exact error 
message(s) that you received.



I suggest you copy and paste the error into something like gist.github.org or 
paste.openstack.org and share a link to that buffer in email. Please make sure 
you sanitize it and remove your password and stuff like that.



Thanks,



-amrith



From: Raman Gupta [mailto:raman.op...@gmail.com]
Sent: Monday, November 14, 2016 8:27 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] git review command authentication failed 



I apologise for this email here. II should have mailed it in general list.



Regards,

Raman Gupta



On Mon, Nov 14, 2016 at 6:47 PM, Raman Gupta  > wrote:

Hello,



I am trying to submit my first change set. I have setup my launchpad account 
and then signed in https://review.openstack.org/. In the setting column (HTTP 
Password) of https://review.openstack.org/, I got a username and generated 
password.



I am using the above username and password in the prompt to successfully 
complete git review command which results in authentication failure.



Where am I doing the mistake?



Regards,

Raman Gupta





smime.p7s
Description: S/MIME cryptographic 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] git review command authentication failed

[Raman Gupta]

I apologise for this email here. II should have mailed it in general list.

Regards,
Raman Gupta

On Mon, Nov 14, 2016 at 6:47 PM, Raman Gupta  wrote:

> Hello,
>
> I am trying to submit my first change set. I have setup my launchpad
> account and then signed in https://review.openstack.org/. In the setting
> column (HTTP Password) of https://review.openstack.org/, I got a username
> and generated password.
>
> I am using the above username and password in the prompt to successfully
> complete git review command which results in authentication failure.
>
> Where am I doing the mistake?
>
> Regards,
> Raman Gupta
>
__
OpenStack Development Mailing List (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] git review command authentication failed

[Raman Gupta]

Hello,

I am trying to submit my first change set. I have setup my launchpad
account and then signed in https://review.openstack.org/. In the setting
column (HTTP Password) of https://review.openstack.org/, I got a username
and generated password.

I am using the above username and password in the prompt to successfully
complete git review command which results in authentication failure.

Where am I doing the mistake?

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

[openstack-dev] [ironic] Removing agent vendor passthru and unsupported drivers

[Pavlo Shchelokovskyy]

Hi Ironicers,

currently I'm busy with removing the lookup/heartbeats "as vendor passthru"
from Ironic which we slated for removal in Ocata, and have the following
question.

Removing the old agent vendor passthru requires changes to some unsupported
drivers whose copies are already in ironic-staging-drivers. The drivers in
question are WoL, iBoot and especially AMT (which uses a custom
not-so-vendor passthru).

AFAIU according to our third-party drivers policy, those unsupported
drivers have to be removed from Ironic tree anyway (as there is no plan to
test them on third-party CI AFAIK) and this looks like a perfect time to do
it.

So ideally I'd like to fix those in ironic-staging-drivers and then remove
them from Ironic tree via a depends-on patch.

What do you think on such plan?

Cheers,
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-dev] [Congress] Magnum_driver

[Ruben]

Hi everybody,
I've added the magnum_driver code, that I'm trying to write for congress, to 
review.
I think that I've made some errors.

I hope in your help.
Ruben

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

[milanisko k]

Hello API WG!

I'd like to ask about possible ``=in:``[1] operator negation implementation
Should the implementation be a negative field name such as
``?state=in:a,b,c_state=in:x,y,z``?
Or rather a negated operator: ``?state=in:a,b,c=not_in:x,y,z``?
There already is the ``=neq:`` operator specified in the filtering
spec[1], so I guess ``=not_in:/=nin:/=out:`` might be more appropriate?

Thanks!
milan

[1]
http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering
__
OpenStack Development Mailing List (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] [infra][neutron] Intel NFV CI voting permission in Neutron

[Znoinski, Waldemar]

Hi Neutron, Infra Cores et al,
I would like to acquire voting (+/-1 Verified) permission for our Intel NFV CI.

1. It's running on Neutron changes since Q1'2015.
2. Wiki [1].
3. It's using openstack-infra/puppet-openstackci [2] with Zuul 2.1.1 for last 8 
months: zuul, gearman, Jenkins, nodepool, local Openstack cloud with VMs and 
baremetal servers (where needed).
4. We have a team of 2 people + me + Nagios looking after it. Its problems are 
fixed promptly and rechecks triggered after non-code related issues. It's being 
reconciled against ci-watch [3] and gerrit using [4].
5. It has a good record of testing for Nova, also voting for last 4 months [5].

[1] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI
[2] https://github.com/openstack-infra/puppet-openstackci
[3] http://ci-watch.tintri.com/project?project=neutron
[4] https://review.openstack.org/#/c/382262/
[5] 
https://review.openstack.org/#/q/reviewer:%22Intel+NFV-CI+%253Copenstack-nfv-ci%2540intel.com%253E%22

Regards
Waldek

Waldemar Znoinski
Software Applications Engineer
+353 (0) 6 1477 782
Intel Research and Development Ireland Ltd
Dromore House, East Park
Shannon, Co. Clare, Ireland

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
OpenStack Development Mailing 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] More file injection woes

[Daniel P. Berrange]

On Fri, Nov 11, 2016 at 07:11:51PM -0600, Matt Riedemann wrote:
> Chris Friesen reported a bug [1] where injected files on a server aren't in
> the guest after it's evacuated to another compute host. This is because the
> injected files aren't persisted in the nova database at all. Evacuate and
> rebuild use similar code paths, but rebuild is a user operation and the
> command line is similar to boot, but evacuate is an admin operation and the
> admin doesn't have the original injected files.
> 
> We've talked about issues with file injection before [2] - in that case not
> being able to tell if it can be honored and it just silently doesn't inject
> the files but the server build doesn't fail. We could eventually resolve
> that with capabilities discovery in the API.
> 
> There are other issues with file injection, like potential security issues,
> and we've talked about getting rid of it for years because you can use the
> config drive.
> 
> The metadata service is not a replacement, as noted in the code [3], because
> the files aren't persisted in nova so they can't be served up later.
> 
> I'm sure we've talked about this before, but if we were to seriously
> consider deprecating file injection, what does that look like?  Thoughts off
> the top of my head are:
> 
> 1. Add a microversion to the server create and rebuild REST APIs such that
> the personality files aren't accepted unless:
> 
> a) you're also building the server with a config drive
> b) or CONF.force_config_drive is True
> c) or the image has the 'img_config_drive=mandatory' property
> 
> 2. Deprecate VFSLocalFS in Ocata for removal in Pike. That means libguestfs
> is required. We'd do this because I think VFSLocalFS is the one with
> potential security issues.

Yes, VFSLocalFS is the dangerous one if used with untrustworthy disk images
(essentially all public cloud images are untrustworth) because malicious
images could be used to exploit bugs in the host kernels' filesystem drivers.
This isn't theoretical - we've seen bugs in popular linux filesystems (ie
ext3) lie mistakenly unfixed for years https://lwn.net/Articles/538898/

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

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

[openstack-dev] [Neutron] Bug Deputy Report

[Andreas Scheuring]

Hi everybody, 
as I cannot join todays Neutron meeting, I wanted to give a brief update
via ML. All bugs are tracked in the following etherpad:

https://etherpad.openstack.org/p/bugs-2016-11-08

Of interest are the sections

- High/Critical
- Tagged but not able to confirm (reaching out to subsystem maintainers
to do triaging)



-- 
-
Andreas 
IRC: andreas_s 





__
OpenStack Development Mailing 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/vmware-nsx installation instructions

[Gary Kotton]

Hi,
Which driver do you plan to use?
You can see the relevant configuration settings via 
https://github.com/openstack/vmware-nsx/tree/master/devstack/lib
Thanks
Gary

From: Micheal B 
Reply-To: OpenStack List 
Date: Saturday, November 12, 2016 at 7:04 AM
To: OpenStack List 
Subject: [openstack-dev] openstack/vmware-nsx installation instructions

What are the steps to install the vmware-nsx nuetron drivers from  
https://github.com/openstack/vmware-nsx?

install -r requirements.txt and the  python setup.py install I got but just 
cannot remember how to generate the nsx.ini file .. tox?

And if there’s any further documentation links or howto’s on the nsx drivers 
that would be great as well.

thanks

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

Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core

[Radomir Dopieralski]

+1

On Mon, Nov 14, 2016 at 1:24 AM, Richard Jones 
wrote:

> Hi Horizon core team,
>
> I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
> solid Horizon contributor for some time, with thoughtful and helpful
> reviews showing good judgment and good knowledge of Horizion and
> related systems. Please respond with your votes by Friday.
>
>
> Thanks,
>
> Richard
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev