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

[Clint Byrum]

Excerpts from Adam Young's message of 2015-10-19 22:53:14 +0900:
> While I tend to play up  bug 968696 for dramatic effect, the reality is 
> we have a logical contradiction on what we mean by 'admin' when talking 
> about RBAC.
> 
> In early iterations of OpenStack, roles were global.  This is reflected 
> in many of the Policy checks that only look for the global role.  
> However, prior to the Keystone-Light rewrite, role assignments became 
> scoped to tenants.  This shows up in the Keystone git history.  As this 
> pattern got established, some people wrote policy checks that assert:
> 
>   role==admin and tenant_id=resource.tenant_id
> 
> This contradicts the global-ness of the admin roles.  If I assign
> ('joeuser', 'admin','mytenant') I've just granted them the ability to 
> perform all of the admin operations.
> 
> Thus, today we have a situation where, unless the user rewrites the 
> default policy, they have to only assign the role  admins to users that 
> are trusted to be admins on the whole deployment.
> 
> We have a few choices.
> 
> 1.  Remove Admin from the scoping for projects. Admin is a special role 
> reserved only for system admins.  Replace project scoped admins with 
> 'manager' or some other comparable role.  This is actually the easiest 
> solution.
> 
> 2.  Create a special project for administrative actions.  Cloud admin 
> users are assigned to this project. Communicate that project Id to the 
> remote systems.  This is what the policy.v3cloudsample.json file 
> (http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json)
>  
> recommends.
> 
> However, 2 is really not practical without some significant 
> engineering.  For a new deployment, it would require the following steps.
> 1) Every single policy file would have to be "templatized"
> 2) Then deployment mechanism would have to create the admin project, get 
> the id for it, and string replace it in the policy file.

I'm glad we're hashing the details of this out, because I've always
found policy file maintenance daunting because of the weird juxtaposition
between careful role assignment, and the user-0 super user access that
'admin' grants.

Can I ask one thing though, can we use a domain name + project _name_
and not the ID?

Using ids in config files means that you cannot configure a service
until after Keystone has been initialized and loaded with data. Of
course this is totally doable, but it puts a huge burden on the config
layer.

However, using logical names means that the physical, random ID that gets
assigned is irrelevant to the configuration step, and thus one can have
a much easier to understand configuration process with static options.

My understanding is that domain+project is a unique ID in Keystone, so
is there any reason not to use that?

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

Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

[Kevin Benton]

Awesome. Thanks for doing this!

On Fri, Oct 23, 2015 at 6:23 AM, Akihiro Motoki  wrote:

> Hi Neutron folks,
>
> We are pleased to announce Neutron social meet-up in Tokyo.
> Thanks Takashi and Hirofumi for the big help.
>
> I hope many of you will be there and enjoy the time.
> If you have made RSVP, don't miss it!
> We recommend  to join the beginning, but come and join us even if you
> arrive late.
>
> 
>
> Thursday, Oct 29 19:00-22:00
> Hokkaido (北海道 品川インターシティー店)
>
> Location:
>
> https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0&usp=sharing
> 5th floor at the "shop and restaurant building" (between A and B
> buildings).
> It is at the opposite side of JR Shinagawa Station from the Summit side.)
>
> Approximately it costs ~5000 (Japanese) Yen depending on the number of
> folks who join.
> Note that we have no sponsors.
>
> If you have any trouble in reaching there or some question, reach me
> @ritchey98 on Twitter.
>
> 
>
> See you in Tokyo!
> Akihiro
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [fuel] [puppet] State of collaboration: it just works

[Dmitry Borodaenko]

I haven't been sending Fuel-Puppet "state of collaboration" emails for a
while now. First couple of months, both projects were very cautious and
it took a great deal of number crunching and persuasion to demonstrate
that the efforts to reconcile are going pay off. Now, I already have
seen enough benefits for both projects to confidently say: yes, it did
pay off, and it's worth going forward with this and doing more of the
same.

Lets have a closer look at the facts to see if my impression is correct.

Last 30 days contribution stats, compared to August [0]:

Denis Egorenko (#2):   87.5% -> 76.7%  (disagreements 13.9% -> 4.8%)
Alex Schultz (#4): 80%   -> 93.0%  (disagreements 26.7% -> 9.6%)
Ivan Berezovskiy (#7): 92.3% -> 91.2%  (disagreements 3.8%  -> 7.0%)
Sergey Kolekonov:  95.7% -> 69.2%  (disagreements 13%   -> 15.4%)
Ekaterina Chernova: 100.0% (disagreements 23.5%)
Max Yatsenko:  100%  -> 100.0% (disagreements 17.4% -> 6.7%)
Kirill Zaitsev: 91.7%  (disagreements 0%)
Matthew Mosesohn:   80.0%  (disagreements 0%)
Alexander Tivelkov: 100.0% (disagreements 0%)

[0] http://lists.openstack.org/pipermail/openstack-dev/2015-August/072313.html

First thing that sticks out is that the + percentage seems to have gone
up for most reviewers (except Denis and Sergey: nice job both of you!).
Considering that the same is true across the board (only 3 of top 10
reviewers are below 90%), while the disagreements percentage has gone
down noticeably, I choose to interpret this as a sign of an improvement
in quality of initial submissions, rather than reduced scrutiny.

Between 9 of 20 top reviewers and 30.4% of reviews, I think it's fair to
pronounce that Puppet OpenStack benefits from a high-quality code review
effort contributed by Fuel developers. A fact obviously recognized by
the project as Denis, our best upstream reviewer, was nominated and
approved as a core in PuppetOpenstack. Thanks Emilien!

Still, it would be nice if the load was spread out more evenly among
more than a handful of top reviewers, with more top reviewers
contributing equally to both fuel-library and upstream (thanks Alex!).

Weekly IRC meeting participation has also continued to improve:

Oct-6: 10 of 18 participants, 104 of 276 lines
Oct-13: 9 of 23 participants, 80 of 307 lines
Oct-20: 9 of 18 participants, 62 of 171 lines

Commit stats remain good, although not quite as good as I expected:

Over the first two weeks of October, we've got 14 commits merged (15.2%
of total commits merged), which is slightly down from 19 commits (18.4%)
in August. At the same time, patch sets per commit ratio has crept up
from 5.6 to 7.14 (while average for Puppet OpenStack went down from 6.5
to 4.38), and Fuel's share of patch sets has gone up from 15.9% to
24.8%). I think we can and should do better here, I've seen Puppet team
merge the first patch set immediately when it's simple enough [1], and
there haven't been any Fuel related commits stuck without review for a
few weeks now.

[1] https://review.openstack.org/236169

On the other hand, the progress with eliminating duplication of Puppet
OpenStack code in fuel-library is much better than I expected: we don't
have any forks of Puppet OpenStack code left in fuel-library.

Of 60 modules in fuel-library, 32 are now managed by librarian and
pulled into fuel-library package at build time [2].

[3] 
https://github.com/openstack/fuel-library/blob/master/deployment/update_modules.sh

This includes 9 modules from Puppet OpenStack project:
- ceilometer
- cinder
- glance
- heat
- horizon
- ironic
- keystone
- neutron
- nova

Of the modules remaining inside fuel-library, there's two that overlap
with Puppet OpenStack even though they are not forks: ceph and murano.
We plan to replace the former with the upstream puppet-ceph module as
part of upgrading the supported Ceph release from Firefly to Hammer in
Fuel 8.0. For the latter, we have put the Fuel module on life support
and started a clean-room reimplementation in upstream [4] in September,
and we will switch to that as soon as it reaches feature parity with the
Fuel version (which I expect to be only a few commits away).

[4] 
https://github.com/openstack/puppet-murano/commit/518800e37f4f8805ce489ca58169299accc346e1

There's going to be more work to migrate the few remaining non-OpenStack
modules to librarian (haproxy, mysql, rabbitmq etc.), but at least for
the OpenStack modules we're in a good shape. Once again, many thanks to
Alex Schultz for starting and spearheading this work!

Comparing the upstream contribution numbers with commit, patch set, and
review stats in fuel-library over the same time period (600 patch sets,
626 reviews) tells me that upstream Puppet OpenStack contribution now
constitutes 15-25% of the Puppet related development effort in Fuel,
while constituting 25-30% of total development effort that goes into
Puppet OpenStack. In other words, roughly 15-20% of combined Fuel
Library

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

[William M Edmonds]

Adam Young  wrote on 10/22/2015 10:31:12 AM:
> On 10/22/2015 05:16 AM, William M Edmonds wrote:
> Adam Young  wrote on 10/19/2015 09:53:14 AM:
> > While I tend to play up  bug 968696 for dramatic effect, the reality is

> > we have a logical contradiction on what we mean by 'admin' when talking

> > about RBAC.
> >
> > In early iterations of OpenStack, roles were global.  This is reflected

> > in many of the Policy checks that only look for the global role.
> > However, prior to the Keystone-Light rewrite, role assignments became
> > scoped to tenants.  This shows up in the Keystone git history.  As this

> > pattern got established, some people wrote policy checks that assert:
> >
> >       role==admin and tenant_id=resource.tenant_id
> >
> > This contradicts the global-ness of the admin roles.  If I assign
> > ('joeuser', 'admin','mytenant') I've just granted them the ability to
> > perform all of the admin operations.
> >
> > Thus, today we have a situation where, unless the user rewrites the
> > default policy, they have to only assign the role  admins to users that

> > are trusted to be admins on the whole deployment.
> >
>
> This all appears to be based on a misassumptions that a) checking
> the project id should be done in policy.json files and b) if it's
> not being checked in the policy file then it's not being checked.
> Neither of those is the case. Many APIs check project id in the
> code, which is where it should be checked. Tokens are scoped to
> projects, thus any use of those tokens should necessarily be scoped
> to the project... otherwise you're not obeying the token scoping.
> The few places that are not already enforcing that in their code
> need to be fixed to start enforcing that. It doesn't make sense to
> do that in policy files, since this is a hard and fast rule, not
> something someone needs to be able to change in policy, or should be
> able to change. Nor would it be practical to put this in policy
> files when you realize that this logic applies to all roles, not just
admin.
>
> I agree that project_id check is better performed in code.  That is
> not the issue here.
>
> Checking Project ID needs to be done, policy file or code does not
> matter.  The problem is more fundamental.
>
> 0. All access is done with Keystone tokens.
> 1. Admin is a role assigned on a project. Always.
> 2. Some APIs have no project with which to check the Scope.

if the URI of the API doesn't include the project, then the code should
limit the request to the scope of the token. No need to check that the
scope of the token matches the scope of the API because scope wasn't
indicated on the API, i.e. scope is implicit based on the token.

> 3. We do not, today, have a means to communicate the scope for an
> admin project.

I don't know what you mean here. "Scope for an admin project"? The scope of
a project is the things that are in that project. And admin is a role that
can exist on any project per #1, i.e., there is no "admin project". We may
need to create the concept of an admin project for keystone in order to
address 968696, but that would be a keystone concept and irrelevant to
nova, cinder, etc.

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

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

[Sergii Golovatiuk]

Hi,

Thank you everyone!

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

On Fri, Oct 23, 2015 at 4:30 PM, Tomasz Napierala 
wrote:

>
> > On 23 Oct 2015, at 16:09, Sergey Lukjanov 
> wrote:
> >
> > Hi folks,
> >
> > component lead elections ended as well.
> >
> > Congrats to Sergii Golovatiuk for becoming official Fuel-library
> component lead!
> >
> > Results:
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_93a6886b38223ab3
>
> Everyone - thanks for voting.
>
> Sergii - please accept my congratulations!
>
> Regards,
> --
> Tomasz 'Zen' Napierala
> Product Engineering - Poland
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [opentack-dev][Tacker] stable/liberty and tacker-docs

[Sridhar Ramaswamy]

Couple of things before heading to M summit,

1) stable/liberty

stable/liberty branch has been pulled. Please cherry pick relevant
fixes as needed. We will make a release after coming back from the summit.

2) Tacker docs

rst files in tacker repo are now available in readthedocs.org at
http://tacker-docs.readthedocs.org/en/latest/

On to Mitaka!

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

[openstack-dev] [Heat] publicURL vs internalURL for resource validation

[Attila Szlovencsak]

Hi!

I am using Openstack Kilo (2015.1.1)
As I learned from the code, heat-engine uses the endpoint-type "publicURL",
when validating templates. I also see that I can override that from
heat.conf via [clients_XXX]/endpoint_type.


heat/engine/clients/os/nova.py

def _create(self):
endpoint_type = self._get_client_option('nova', 'endpoint_type')
management_url = self.url_for(service_type='compute',
  endpoint_type=endpoint_type)


/heat/common/config.py
=
# these options define baseline defaults that apply to all clients
default_clients_opts = [
cfg.StrOpt('endpoint_type',
   default='publicURL',


My questions:

1. Shouldn't we use the  interalURL instead as default?  In a typical case,
the controller node sits behind a load-balancer, and IP for the publicURLs
are held by the load-balancer. The controller node (so heat-engine) might
not have access to the publicURL at all.

2. Instead of creating and "endpoint_type" entry in heat.conf for each and
every service,  is there a simpler way to force using the internalURL?

Thanks in advance,
Attila


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

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

[George Silvis, III]

On 10/22/2015 02:13 PM, Iury Gregory wrote:
> Hi George, can you say day and hour for this working session? Thanks

I'll present this at:

https://mitakadesignsummit.sched.org/event/93adfa1e5a023bc37c4de0bf2a999862

Tuesday, October 27, 5:30-6:10 PM.

-George



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] [app-catalog] [glance] [murano] Data Assets API for App Catalog

[Fox, Kevin M]

The "Glance: Artefacts API" session was scheduled right on top of the "Nova: 
Cross Service Issues: Service Lock Server, Service Tokens, Instance Users 
(TBC)" session. The latter having been really hard to schedule since it 
involves so many different projects and something I must attend. So I won't be 
able to attend the glance session.

The Murano folks have kindly offered to use one of their sessions:
Murano contributors meetup (9:00am-12:30pm)
http://mitakadesignsummit.sched.org/event/5e244fb7f342854dc5c112e76e77c930
to discuss Glance Artefacts/Murano integration/Community App Catalog needs.

Can folks from the glance team that are interested in the discussion please 
attend?

Thanks,
Kevin


From: Alexander Tivelkov [ativel...@mirantis.com]
Sent: Thursday, October 15, 2015 3:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [app-catalog] [glance] [murano] Data Assets API for 
App Catalog

Hi folks,

I’ve noticed that the Community Application Catalog has begun to implement its 
own API, and it seems to me that we are going to have some significant 
duplication of efforts with the code which has already been implemented in 
Glance as Artifact Repository initiative (also known as Glance V3).
>From the very beginning of the App Catalog project (and I’ve been involved in 
>it since February) I’ve been proposing to use Glance as its backend, because 
>from my point of view it covers like 90% of the needed functionality. But it 
>looks like we have some kind of miscommunication here, as I am getting some 
>confusing questions and assumptions, like the vision of Glance V3 being 
>dedicated backend for Murano (which is definitely incorrect).
So, I am writing the email to clarify my vision of what Glance V3 is and how 
its features may be used to provide the REST API for Community App Catalog.

1.  Versioned schema
First of all, Glance V3 operates on entities called “artifacts”, and these ones 
perfectly map to the Data Assets of community app catalog. The artifacts are 
strongly typed: there are artifact types for murano packages, glance images, 
heat templates - and there may be (and will be) more. Each artifact type is 
represented by a plugin, defining the schema of objects’ data and metadata and 
- optionally - custom logic. So, this thing is extensible: when a new type of 
asset needs to be added to a catalog it can be done really quickly by just 
defining the schema and putting that schema into a plugin. Also, these plugins 
are versioned, so the possible changes in the schema are handled properly.

2. Generic properties
Next, all the artifact types in Glance V3 have some generic metadata properties 
(i.e. part of the schema which is common for all the types), including the 
name, the version, description, authorship information and so on. This also 
corresponds to the data schema of community app catalog. The mapping is not 
1:1, but we can work together on this to make sure that these generic 
properties match the expectations of the catalog.

3. Versioning
Versions are very important for catalogs of objects, so Glance V3 was initially 
designed keeping versioning questions in mind: each artifact has a semver-based 
version assigned, so the artifacts having the same name but different versions 
are grouped into the proper sequences. API is able to query artifacts based on 
their version spec, e.g. it is possible to fetch the latest artifact with the 
name “foo” having the version greater than 2.1 and less than 3.5.7 - or any 
other version spec, similar to pip or any other similar tool. As far as I know, 
community app catalog does not have such capabilities right now - and I 
strongly believe that it is really a must have feature for a catalog to be 
successful. At least it is absolutely mandatory for Murano packages, which are 
the only “real apps” among the asset types right now.

4. Cross artifact dependencies
Glance V3 also has the dependency relations from the very beginning, so they 
may be defined as part of artifact type schema. As a result, an artifact may 
“reference” any number of other artifacts with various semantic. For example, 
murano package may define a set of references to other murano packages and call 
it “requires” - and this will act similar to the requirements of a python 
package. Similar properties may be defined for heat templates and glance images 
- they may reference each other with various semantics.
Of course, the definitions of such dependencies may be done internally inside 
the packages, so they may be resolved locally by the service which is going to 
use it, but letting the catalog know about them will allow us to do the 
import-export operations for any given artifacts and its dependencies 
automatically, only by the means of the catalog itself.

5. Search and filtering API
Right now Glance V3 API 

[openstack-dev] [third-party] third party ci operators meetup in Tokyo

[Asselin, Ramy]

Would any 3rd party ci operators like to meetup in Tokyo during the summit?

I would like to propose we have lunch together at one of the summit lunch areas 
on Wednesday, October 28.

Please reply to this thread. You can also message me via google hangouts: 
ramy.asse...@gmail.com.


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

[openstack-dev] Openstack disaster recover with CloudFerry, other tools?

[Jonathan Brownell]

Hello, I'm interested in using technology like CloudFerry
[https://github.com/MirantisWorkloadMobility/CloudFerry] to migrate
OpenStack resources from one cloud to another in the use case of
disaster recovery.

I can deal with the storage replication necessary to make sure that
the storage backend(s) are regularly freshened in the failover cloud,
and its files will just need to be reattached to Cinder volume and
Glance image objects during reconstruction (in preparation for
association with new, failed-over compute instances).

CloudFerry is designed to migrate resources from one cloud to another
while both environments are accessible and operable (i.e. its primary
"Openstack version upgrade" scenario). So, for my use case, I expect
to have to define metadata that would be regularly collected (via APIs
and DB), transmitted, and cached on the failover side in order to
perform a recovery if the primary cloud goes completely offline.

I can see a number of OpenStack Summit presentations over the years
that describe this kind of method for failing over resources from one
cloud to another to address disaster recovery, but have not found any
other projects or tools that help accomplish this. Is there work in
the community that targets this kind of functionality today that I
should familiarize myself with? Or any huge red flags I'm missing that
would prohibit this kind of solution from working?

Thanks,

-JB

__
OpenStack Development Mailing List (not 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] unit test improvements: work with DOM, not raw HTML strings?

[Timur Sufiev]

+1 here. While the exact library choice may still be a topic for the
discussion, unit tests clearly shouldn't hardcode html stings inside, it is
too fragile.
On Fri, 23 Oct 2015 at 02:00, Diana Whitten  wrote:

> Richard,
>
> I'm absolutely with you ... I've been bitten by these very tests recently
> when changing a class in a simple template.  If anyone wants to override
> these templates in the future, then they are forced to fight this
> 'expected_string' test as well.
>
> I think this is a good idea.
>
> - Diana
>
> On Thu, Oct 22, 2015 at 3:52 PM, Richard Jones 
> wrote:
>
>> Hi all,
>>
>> I've noticed that we have quite a few places in our unit test suite that
>> test for correctness of behaviour by searching for quite complex HTML
>> fragments in page renders. An example would be
>> openstack_dashboard/dashboards/project/access_and_security/floating_ips/tests.py
>>
>> (there's plenty more - search for "expected_string")
>>
>> The code in question is testing far more than it should. We are testing
>> for the presence of the "disabled" class in an element which has a clear id
>> attribute by constructing the whole element HTML, including label and title
>> text, glyph icon, other classes, the tag type itself, etc. All of those
>> things are quite irrelevant to the test in question, but any change to
>> those will cause the test to break unnecessarily.
>>
>> In these cases a far more robust and targeted unit test would construct a
>> DOM from the rendered HTML and use semantic searches to determine the
>> correctness of behaviour. I would recommend we consider using something
>> like https://django-with-asserts.rtfd.org/ which allow us to write:
>>
>>  with self.assertHTML(res, element_id='security_groups__action_create')
>> as elem:
>> self.assertContains(elem.attrib['class'], 'disabled')
>>
>> Who's with me?
>>
>>
>> Richard
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Manila] Stackalytics 0.9: new features and improvements

[Sturdevant, Mark]

Hey Manila CI maintainers,

I added [Manila] to the subject to get your attention, but the details are from 
an earlier post below.  Notice there is a nice new Manila CI report at 
http://stackalytics.com/report/ci/manila/7.  Unfortunately most of the Manila 
drivers are not in driverlog yet, so they don't show up in the report.  Please 
update driverlog with your CI and contact info.

Regards,
MarkStur




From: Ilya Shakhat [ishak...@mirantis.com]
Sent: Friday, October 23, 2015 2:26 AM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] Stackalytics 0.9: new features and improvements

Hi all,

During the last month we've made a number of changes and improvements in 
Stackalytics that deserve version tag and special announcement. The most 
important feature is tracking history of official projects list - highly 
demanded after shift to 'big tent' model.

The full list of changes below:

1. Stackalytics now respects history of changes in the official programs list. 
Changes are tracked per-release, so if some project was accepted officially in 
Liberty, it does not appear in the past and thus does not affect Kilo stats. As 
anchor points we use tags in governance repo (e.g. 
april-2015-elections)[1]. 
These tags are related to elections and created a bit before the release thus 
saving from last-minute changes in the stats.

2. With removal of Stackforge, all projects are now classified in 2 groups: 
'OpenStack' = listed in the official projects.yaml 
[2]
 and 'OpenStack Others' = those that are in openstack organization, but not 
accepted officially. As before, by default Stackalytics shows official projects.

3. CI metric [3] is redesigned from 
scratch. Now it analyses votes in merged patches only, the numbers are shown 
for every driver. List of drivers is synced with DriverLog 
[4].

4. Added a new driver status report 
[5]. The report shows total number 
of votes, success rate and the latest result per every driver per module. The 
report is available for projects that have external CI configured (Nova, 
Neutron, Cinder, Manila, Sahara, number of Fuel plugins) The data may be not 
complete now and requires proper configuration in DriverLog's default data 
(maintainers are welcome to contribute into 
[4])

5. Abandoning a change request is now treated as reviewing 
[6] and is included into review 
metric. Only abandoning of other's CRs is taken into account.

6. Reviews for own patches are not included into the stats anymore. In the 
activity log such reviews are marked with prefix 'Self-' (e.g. Self-Code-Review 
and Self-Approve)

7. Review processing is made compatible with Gerrit 2.9+, making Stackalytics 
ready for infra upgrade.

Thanks,
Ilya

[1] - https://git.openstack.org/cgit/openstack/governance/
[2] - 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[3] - http://stackalytics.com/?metric=ci
[4] - 
http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
[5] - http://stackalytics.com/report/ci/cinder/7
[6] - https://bugs.launchpad.net/bugs/1498769

__
OpenStack Development Mailing List (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] [Tacker] Mitaka Design Summit meetup

[Sridhar Ramaswamy]

Heads for the folks interested in Tacker. A developer meetup is planned for
Wed Oct 28th - 9:30am - 12noon. Exact location in the venue will be
finalized early next week. The following etherpad captures the current
topics to interest,

https://etherpad.openstack.org/p/mitaka-tacker-design-summit

Feel free to add as need in the etherpad.

See you all in Tokyo!
Sridhar
__
OpenStack Development Mailing List (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][nova][cinder][horizon][searchlight][cross-project] image property protections design session

[Brian Rosmaita]

tl;dr  Word on the street is that image property protections are a pain
point for some projects (e.g., Nova, Cinder).  We'd like to find out from
some other projects (and deployers) how they interact with Glance with
respect to property protections and how we can improve this process.

The Glance team is holding a design summit session on cross-project
property protection support, Thursday Oct 29, 9:00-9:40am (Amethyst room).
 The more projects represented at this session, the better it will be.

Details are here: http://sched.co/4Qaq

cheers,
brian



__
OpenStack Development Mailing List (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] [barbican] Weekly meetings cancelled for Summit

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Barbicaneers,

Since a lot of us are going to be traveling to Tokyo for the Summit
next week, I figured we should probably cancel the next couple of
weekly meetings.  The next weekly meeting will be on Nov 9 @ 2000 UTC.

Thanks,
Douglas Mendizábal
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWKmDgAAoJEB7Z2EQgmLX7ApMP/inPg02zYeAPg7eBifkyRCR2
YOdlTQUO8aUjk1rF5ZrFuuqvutXe7HPfU1ZsWDHX/8F4nYJQhfUgprv0iTEG3fY2
KC0A0oFbMex8CHuCyLNOQtJAkIQRXdVWZwP8ynz/Yl5l5jzSc5UaN1AwcnRuf4eV
7srcFny/vsb4ZAhdq3LgqsJibijggUt6o3DKOypFt5G8eyjjkGZajtlg3VHBrnly
EG0hPNIRbrzxuI9OtsfICHUotOqou1iaN+6toFkGYE+aYRhua5O0BjRewyWhrLg+
333A09I1Fd8q8XrO3kAvo1Pm6Ax/x/TzH1YouJWCcEb45m9C8FOSLMnkte5ZunYM
foj9iv+wexZxQTBybWBRyOKVeIQxRr30QLwIq4O/h81LNw/BO+XjIoeMaaLD33Xk
iPYkt0c6DWgXE3IM+rhwDDf4ikv/M8jFu6MyLeJnncKSdeB4yBV9v75ihhQZC7R3
oHrnhoTz4WibWDOxU2kM7EU+px1WtjJNySDvTVDLNZaDVTsXhMeJIKo8p1VwT56U
N8RMjuobP96Id6GN1m/wszKYgosN32F9Npptx4z/hfEAnr/aqqj4VsRCoM5pZcJU
9x2m+JJkFse7aLaVCiBJPefqx99yNl6vn1cwcKc45FCWqOjP5V6+eDSFIaBLnGpE
gaqDbG7K6I4iNpeaPTTE
=4d7P
-END PGP SIGNATURE-

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

[openstack-dev] [Zaqar] No meeting until 9 Nov

[Fei Long Wang]

Hi everyone,

As we discussed in last meeting, we won't be holding our weekly meetings until 
after summit. Normal weekly meeting will resume on Nov 9. The time for the
meeting that week will be 21:00 UTC. Thanks.

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
OpenStack Development Mailing List (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] Neutron Social Meetup in Tokyo

[Akihiro Motoki]

Hi Neutron folks,

We are pleased to announce Neutron social meet-up in Tokyo.
Thanks Takashi and Hirofumi for the big help.

I hope many of you will be there and enjoy the time.
If you have made RSVP, don't miss it!
We recommend  to join the beginning, but come and join us even if you
arrive late.



Thursday, Oct 29 19:00-22:00
Hokkaido (北海道 品川インターシティー店)

Location:
https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0&usp=sharing
5th floor at the "shop and restaurant building" (between A and B buildings).
It is at the opposite side of JR Shinagawa Station from the Summit side.)

Approximately it costs ~5000 (Japanese) Yen depending on the number of
folks who join.
Note that we have no sponsors.

If you have any trouble in reaching there or some question, reach me
@ritchey98 on Twitter.



See you in Tokyo!
Akihiro

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

Re: [openstack-dev] [Fuel] fuelmenu code freeze

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to update the status of the activity (moving fuelmenu to a
separate repo).


   - Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506885
   - project-config patch https://review.openstack.org/#/c/235177 (DONE)
   - pypi (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12865 (DONE)
   - label jenkins slaves for verification (TODO CI-team)
   - directory freeze (DONE)
   - prepare upstream (DONE)
   - waiting for project-config patch to be merged (DONE)
   - .gitreview https://review.openstack.org/#/c/238434/ (DONE)
   - .gitignore https://review.openstack.org/238528 (ON REVIEW)
   - custom jobs parameters https://review.fuel-infra.org/13088 (ON REVIEW)
   - fix core group (DONE)
   - fuel-main https://review.openstack.org/#/c/238459/ (ON REVIEW)
   - packaging-ci (TODO)
   - MAINTAINERS https://review.openstack.org/238976 (ON REVIEW)
   - deprecate fuelmenu directory https://review.openstack.org/#/c/238972/
   (ON REVIEW)

There are still some patches on review that you can help to get merged.


Vladimir Kozhukalov

On Tue, Oct 20, 2015 at 7:05 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Igor,
>
> Thank you for your help. I'd say ETA is today/tomorrow and depends on how
> quickly this project-config patch [1] will be reviewed and merged. I'll ask
> openstack-infra guys to do this ASAP.
>
> [1] https://review.openstack.org/#/c/235177
>
> Vladimir Kozhukalov
>
> On Tue, Oct 20, 2015 at 6:39 PM, Igor Kalnitsky 
> wrote:
>
>> Hey Vladimir,
>>
>> That's awesome news. I blocked all fuelmenu patches [1] with a link to
>> this thread. So don't worry, we won't merge them accidentally.
>>
>> BTW, could you provide any ETA when moving will be done?
>>
>> [1]
>> https://review.openstack.org/#/q/project:openstack/fuel-web+file:%255Efuelmenu.*+status:open,n,z
>>
>> Thanks,
>> Igor
>>
>> On Tue, Oct 20, 2015 at 5:58 PM, Vladimir Kozhukalov
>>  wrote:
>> > Dear colleagues,
>> >
>> > As you might know I'm working on splitting multiproject fuel-web
>> repository
>> > into several sub-projects. Fuelmenu is one of directories that are to be
>> > moved to a separate git project.
>> >
>> > Checklist for this to happen is as follows:
>> >
>> > Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
>> > project-config patch https://review.openstack.org/#/c/235177 (ON REVIEW
>> > WORKFLOW -1)
>> > pypi project
>> https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=Fuel-menu
>> > (DONE)
>> > run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
>> > rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
>> > fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON
>> REVIEW)
>> > label jenkins slaves for verification jobs (ci team)
>> > directory freeze (WE ARE HERE)
>> > prepare upstream (TODO)
>> > project-config (ON REVIEW)
>> > fuel-main patch (TODO)
>> > packaging-ci patch (TODO)
>> > deprecate fuel-web/fuelmenu directory (TODO)
>> >
>> > Now we are at the point where we need to freeze fuel-web/fuelmenu
>> directory.
>> > So, I'd like to announce code freeze for this directory and all patches
>> that
>> > make changes in the directory and are currently on review will need to
>> be
>> > backported to the new git repository.
>> >
>> >
>> > Vladimir Kozhukalov
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] Bug Triage (27 Oct) and Project Meeting (29 Oct) cancelled

[Jesse Pretorius]

Hi everyone,

Due to the summit next week, the Bug Triage on Tuesday and the Project
Meeting on Thursday will not be taking place. Hopefully we'll be seeing
most of you at the summit, but if not then we'll be catching up again with
all meetings resuming in November.

Have a great week!

Jesse

-- 
Jesse Pretorius
IRC: odyssey4me
__
OpenStack Development Mailing List (not 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-compute][nova][libvirt] Extending Nova-Compute for image prefetching

[Markus Zoeller]

Mathieu Gagné  wrote on 10/22/2015 08:08:07 PM:
> > Could you maybe add a short explanation what the use case is? IOW,
> > when and why do I (in whatever role) prefetch images? 
> > 
> 
> This previous OpenStack Summit presentation at Paris is a great example
> of use case:
> https://www.openstack.org/summit/openstack-paris-summit-2014/session-
> videos/presentation/cold-start-booting-of-1000-vms-under-10-minutes
> 
> -- 
> Mathieu

Thanks, that's a great presentation with impressive numbers. I wasn't
aware that there could be the need to distribute new images such often.

Regards, Markus Zoeller (markus_z)


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

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

[Tomasz Napierala]

> On 23 Oct 2015, at 16:09, Sergey Lukjanov  wrote:
> 
> Hi folks,
> 
> component lead elections ended as well.
> 
> Congrats to Sergii Golovatiuk for becoming official Fuel-library component 
> lead!
> 
> Results: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_93a6886b38223ab3

Everyone - thanks for voting.

Sergii - please accept my congratulations!

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







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

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

[Sergey Lukjanov]

Hi folks,

component lead elections ended as well.

Congrats to Sergii Golovatiuk for becoming official Fuel-library component
lead!

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

Thanks.

On Tue, Oct 20, 2015 at 4:48 AM, Mike Scherbakov 
wrote:

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

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Rich Megginson]

On 10/22/2015 11:09 PM, Gilles Dubreuil wrote:


On 21/10/15 00:56, Sofer Athlan-Guyot wrote:

Gilles Dubreuil  writes:


On 14/10/15 17:15, Gilles Dubreuil wrote:


On 14/10/15 10:36, Colleen Murphy wrote:


On Tue, Oct 13, 2015 at 6:13 AM, Vladimir Kuklin mailto:vkuk...@mirantis.com>> wrote:

 Puppetmaster and Fuelers,

 Last week I mentioned that I would like to bring the theme of using
 native ruby OpenStack client and use it within the providers.

 Emilien told me that I had already been late and the decision was
 made that puppet-openstack decided to not work with Aviator based on
 [0]. I went through this thread and did not find any unresolvable
 issues with using Aviator in comparison with potential benefits it
 could have brought up.

 What I saw actually was like that:

 * Pros

 1) It is a native ruby client
 2) We can import it in puppet and use all the power of Ruby
 3) We will not need to have a lot of forks/execs for puppet
 4) You are relying on negotiated and structured output provided by
 API (JSON) instead of introducing workarounds for client output like [1]

 * Cons

 1) Aviator is not actively supported
 2) Aviator does not track all the upstream OpenStack features while
 native OpenStack client does support them
 3) Ruby community is not really interested in OpenStack (this one is
 arguable, I think)

 * Proposed solution

 While I completely understand all the cons against using Aviator
 right now, I see that Pros above are essential enough to change our
 mind and invest our own resources into creating really good
 OpenStack binding in Ruby.
 Some are saying that there is not so big involvement of Ruby into
 OpenStack. But we are actually working with Puppet/Ruby and are
 invloved into community. So why should not we own this by ourselves
 and lead by example here?

 I understand that many of you do already have a lot of things on
 their plate and cannot or would not want to support things like
 additional library when native OpenStack client is working
 reasonably well for you. But if I propose the following scheme to
 get support of native Ruby client for OpenStack:

 1) we (community) have these resources (speaking of the company I am
 working for, we at Mirantis have a set of guys who could be very
 interested in working on Ruby client for OpenStack)
 2) we gradually improve Aviator code base up to the level that it
 eliminates issues that are mentioned in  'Cons' section
 3) we introduce additional set of providers and allow users and
 operators to pick whichever they want
 4) we leave OpenStackClient default one

 Would you support it and allow such code to be merged into upstream
 puppet-openstack modules?


 [0] 
https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
 [1] 
https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04 
 +7 (926) 702-39-68 
 Skype kuklinvv
 35bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com 
 www.mirantis.ru 
 vkuk...@mirantis.com 


The scale-tipping reason we went with python-openstackclient over the
Aviator library was that at the same time we were trying to switch, we
were also developing keystone v3 features and we could only get those
features from python-openstackclient.

For the first two pros you listed, I'm not convinced they're really
pros. Puppet types and providers are actually extremely well-suited to
shelling out to command-line clients. There are existing, documented
puppet APIs to do it and we get automatic debug output with it. Nearly
every existing type and provider does this. It is not well-suited to
call out to other non-standard ruby libraries because they need to be
added as a dependency somehow, and doing this is not well-established in
puppet. There are basically two options to do this:

  1) Add a gem as a package resource and make sure the package resource
is called before any of the openstack resources. I could see this
working as an opt-in thing, but not as a default, for the same reason we
don't require our users to install pip libraries - there is less
security guarantees from pypi and rubygems than from distro packages,
plus corporate infrastructure may not allow pulling packages from these
types of sources. (I don't see this policy documented anywhere, this was
just something that's been instilled in me since I started working on
this team. If we want to revisit it, formalize it, or drop it, we can
start a separate thread for that.)

2) Vendor the gem as a 

Re: [openstack-dev] [Ironic] BIOS Configuration

[Lucas Alvares Gomes]

Hi,

> I am interested in remote BIOS configuration.
> There is "New driver interface for BIOS configuration specification"
> https://review.openstack.org/#/c/209612/
>
> Is it possible to implement this without REST API endpoint?
>

I may be missing something here but without the API how will the user
set the configurations? We need the ReST API so we can abstract the
interface for this for all the different drivers in Ironic.

Also, feel free to add suggestions in the spec patch itself.

Cheers,
Lucas

__
OpenStack Development Mailing List (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] IRC canceled during summit

[Tim Hinrichs]

As you might expect, next week's IRC is canceled since many of us will be
attending the Tokyo summit.

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

Re: [openstack-dev] [fuel] State of the Fuel gates: liftoff!

[Vladimir Kuklin]

Dmitry

I apologize - I did not notice that the commit depends on other ones to
Fuel Library which actually improve unit tests coverage. Disregard my
previous message, please.



On Fri, Oct 23, 2015 at 2:14 PM, Vladimir Kuklin 
wrote:

> Dmitry
>
> These are awesome news.
>
> BTW, why should we enable unit tests for Fuel Library in voting mode right
> now? It seems not all our modules have them passing. Can we wait a bit and
> recheck it or we will get our master merges blocked?
>
> On Fri, Oct 23, 2015 at 3:25 AM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> Back in July, I proposed a plan to implement PTI in Fuel [0] during Fuel
>> 8.0 development cycle, with the following mandatory stages:
>>
>> Stage 1: Create non-voting gate jobs for a single Fuel repo.
>> Stage 2: Get these gate jobs to pass and make them voting.
>> Stage 3: Create non-voting gate jobs for all Fuel repos.
>> Stage 4: Cover all Fuel repos with voting unit test gate jobs.
>>
>> and bonus stages:
>>
>> Stage 5: Add functional tests for Fuel UI and Fuel Library to the gates.
>> Stage 6: Run fuel-qa (multi-node deployment) tests on OpenStack Infra.
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-July/069908.html
>>
>> With the Kilo based Fuel 7.0 released in September, we were finally able
>> to make some solid progress on that. Of 21 non-plugin Fuel repositories
>> on review.openstack.org, 12 (including one of our two largest core
>> components: fuel-web) already have voting gate jobs, 3 more (including
>> the other largest core component: fuel-library) have passing gate jobs
>> that can become voting once all outstanding fixes are merged, and 3 more
>> are a work in progress.
>>
>> Voting:
>> - fuel-agent
>> - fuel-dev-tools
>> - fuel-devops
>> - fuel-mirror
>> - fuel-octane
>> - fuel-ostf (pep8; python gates are waiting for images with gevent)
>> - fuel-plugins
>> - fuel-specs
>> - fuel-stats
>> - fuel-upgrade
>> - fuel-web
>> - python-fuelclient
>>
>> Ready to vote:
>> - fuel-library (needs https://review.openstack.org/238628)
>> - fuel-menu
>> - shotgun
>>
>> Work in progress:
>> - fuel-astute (has unit tests, needs a gate job)
>> - fuel-docs (docs gate job is failing)
>> - network-checker (unit test gate job is failing)
>>
>> Not covered by unit tests:
>> - fuel-main (scripts to make Fuel ISO)
>> - fuel-nailgun-agent (588 lines of Ruby)
>> - fuel-qa (Fuel deployment system tests)
>>
>> While it might be a bit too early to pull out a "Mission Accomplished"
>> banner, it's safe to say that vast majority of Fuel code is now covered
>> by gate checks running unit tests and syntax checks on OpenStack CI.
>>
>> Nice work Alexey, Alex, Alexander, Sebastian, Vladimir, and Vladimir!
>> Many thanks to the OpenStack Infra team for encouraging and supporting
>> this effort!
>>
>> --
>> Dmitry Borodaenko
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

[Sheena Gregson]

As a reminder: there are no individual networking options that can be used
with both vCenter and KVM/QEMU hypervisors once we deprecate nova-network.



The code for vCenter as a stand-alone deployment may be there, but the code
for the component registry (
https://blueprints.launchpad.net/fuel/+spec/component-registry) is still
not complete.  The component registry is required for a multi-HV
environment, because it provides compatibility information for Networking
and HVs.  In theory, landing this feature will enable us to configure DVS +
vCenter and Neutron with GRE/VxLAN + KVM/QEMU in the same environment.



While Andriy Popyvich has made considerable progress on this story, I
personally feel very strongly against deprecating nova-network until we
have confirmed that we can support *all current use cases* with the
available code base.



Are we willing to lose the multi-HV functionality if something prevents the
component registry work from landing in its entirety before the next
release?



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Friday, October 23, 2015 6:30 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] Remove nova-network as a deployment
option in Fuel?



Hi,



As far as I know neutron code for VCenter is ready. Guys are still testing
it. Keep patience... There will be announce soon.


--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (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] [tricircle][neutron][dragonflow]Joint session at Design Summit Venue

[Zhipeng Huang]

Hi All,

Team Tricircle and Dragonflow will hold joint design session at design
summit venue, and since both teams are not top level official projects, we
will try to gather what we could grab at the site for logistic of the
meeting :)

The time slot for our session would be 1:30-3:30pm, on Wed and Thurs. The
agenda for the session would be to discuss design update and plan for M
release.

Look forward to see y'all at the summit !

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

Re: [openstack-dev] [Fuel] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Dmitry Ilyin]

Here is the implementation of the puppet "command" that outputs only stdout
and drops the stderr unless an error have happened.
https://github.com/dmitryilyin/puppet-neutron/commit/b55f36a8da62fc207a91b358c396c03c8c58981b

2015-10-22 17:59 GMT+03:00 Matt Fischer :

> On Thu, Oct 22, 2015 at 12:52 AM, Sergey Vasilenko <
> svasile...@mirantis.com> wrote:
>
>>
>> On Thu, Oct 22, 2015 at 6:16 AM, Matt Fischer 
>> wrote:
>>
>>> I thought we had code in other places that split out stderr and only
>>> logged it if there was an actual error but I cannot find the reference now.
>>> I think that matches the original proposal. Not sure I like idea #3.
>>
>>
>> Matthew, this topic not about SSL. ANY warnings, ANY output to stderr
>> from CLI may corrupt work of providers from puppet-* modules for openstack
>> components.
>>
>> IMHO it's a very serious bug, that potential affect openstack puppet
>> modules.
>>
>> I see 3 way for fix it:
>>
>>1. Long way. big patch to puppet core for add ability to collect
>>stderr and stdout separately. But most of existing puppet providers waits
>>that stderr and stdout was mixed when handle errors of execution (non-zero
>>return code). Such patch will broke backward compatibility, if will be
>>enabled by default.
>>2. Middle way. We should write code for redefine 'commands' method.
>>New commands should collect stderr and stdout separately, but if error
>>happens return stderr (with ability access to stdout too).
>>3. Short way. Modify existing providers to use json output instead
>>plain-text or csv. JSON output may be separated from any garbage 
>> (warnings)
>>slightly. I make this patch as example of this way:
>>https://review.openstack.org/#/c/238156/ . Anyway json more
>>formalized format for data exchange, than plain text.
>>
>> IMHO way #1 is a best solution, but not easy.
>>
>>
> I must confess that I'm a bit confused about this. It wasn't a secret that
> we're calling out to commands and parsing the output. It's been discussed
> over and over on this list as recently as last week, so this has been a
> known possible issue for quite a long time. In my original email I was
> agreeing with you, so I'm not sure why we're arguing now. Anyway...
>
> I think we need to split stderr and stdout and log stderr on errors, your
> idea #2. Using json like openstack-client can do does not solve this
> problem for us, you still can end up with a bunch of junk on stderr.
>
> This would be a good quick discussion in Tokyo if you guys will be there.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

[Sergii Golovatiuk]

Hi,

As far as I know neutron code for VCenter is ready. Guys are still testing
it. Keep patience... There will be announce soon.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not 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] Returning of HEAD files?

[Anna Kamyshnikova]

Ihar, Mark thank you for your comments!

Change [1] is ready, so we can land it in Neutron. For subprojects it will
be up to them to have HEAD files or not - tests won't fail, just warning
message will be shown.

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

On Fri, Oct 9, 2015 at 8:16 PM, Mark McClain  wrote:

>
> There are pros and cons for both approaches, but overall, I don’t see how
> the former justify having HEAD files and the complexity to handle them in
> code and in file system.
>
>
> The HEAD file is a clear winner when gate load is high and there are
> competing migrations.  As you pointed out PEP8 will detect the problem, but
> not fast enough to cause a ripple in the changes behind it in the gate.
> The ripple causes resources to be wasted adding to the load, so the git
> merge conflict was the best compromise we developed.
>
> mark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] Stackalytics 0.9: new features and improvements

[Flavio Percoco]

On 23/10/15 12:26 +0300, Ilya Shakhat wrote:

Hi all, 

During the last month we've made a number of changes and improvements in
Stackalytics that deserve version tag and special announcement. The most
important feature is tracking history of official projects list - highly
demanded after shift to 'big tent' model. 

The full list of changes below:

1. Stackalytics now respects history of changes in the official programs list.
Changes are tracked per-release, so if some project was accepted officially in
Liberty, it does not appear in the past and thus does not affect Kilo stats. As
anchor points we use tags in governance repo (e.g. april-2015-elections)[1]
. These tags are related to elections and created a bit before the release thus
saving from last-minute changes in the stats.

2. With removal of Stackforge, all projects are now classified in 2 groups:
'OpenStack' = listed in the official projects.yaml [2] and 'OpenStack Others' =
those that are in openstack organization, but not accepted officially. As
before, by default Stackalytics shows official projects.

3. CI metric [3] is redesigned from scratch. Now it analyses votes in merged
patches only, the numbers are shown for every driver. List of drivers is synced
with DriverLog [4]. 

4. Added a new driver status report [5]. The report shows total number of
votes, success rate and the latest result per every driver per module. The
report is available for projects that have external CI configured (Nova,
Neutron, Cinder, Manila, Sahara, number of Fuel plugins) The data may be not
complete now and requires proper configuration in DriverLog's default data
(maintainers are welcome to contribute into [4])

5. Abandoning a change request is now treated as reviewing [6] and is included
into review metric. Only abandoning of other's CRs is taken into account.

6. Reviews for own patches are not included into the stats anymore. In the
activity log such reviews are marked with prefix 'Self-' (e.g. Self-Code-Review
and Self-Approve)

7. Review processing is made compatible with Gerrit 2.9+, making Stackalytics
ready for infra upgrade. 


Awesome work! Thanks for your efforts!

Flavio



Thanks, 
Ilya

[1] - https://git.openstack.org/cgit/openstack/governance/
[2] - http://git.openstack.org/cgit/openstack/governance/tree/reference/
projects.yaml
[3] - http://stackalytics.com/?metric=ci
[4] - http://git.openstack.org/cgit/openstack/driverlog/tree/etc/
default_data.json
[5] - http://stackalytics.com/report/ci/cinder/7
[6] - https://bugs.launchpad.net/bugs/1498769



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



--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [fuel] State of the Fuel gates: liftoff!

[Vladimir Kuklin]

Dmitry

These are awesome news.

BTW, why should we enable unit tests for Fuel Library in voting mode right
now? It seems not all our modules have them passing. Can we wait a bit and
recheck it or we will get our master merges blocked?

On Fri, Oct 23, 2015 at 3:25 AM, Dmitry Borodaenko  wrote:

> Back in July, I proposed a plan to implement PTI in Fuel [0] during Fuel
> 8.0 development cycle, with the following mandatory stages:
>
> Stage 1: Create non-voting gate jobs for a single Fuel repo.
> Stage 2: Get these gate jobs to pass and make them voting.
> Stage 3: Create non-voting gate jobs for all Fuel repos.
> Stage 4: Cover all Fuel repos with voting unit test gate jobs.
>
> and bonus stages:
>
> Stage 5: Add functional tests for Fuel UI and Fuel Library to the gates.
> Stage 6: Run fuel-qa (multi-node deployment) tests on OpenStack Infra.
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/069908.html
>
> With the Kilo based Fuel 7.0 released in September, we were finally able
> to make some solid progress on that. Of 21 non-plugin Fuel repositories
> on review.openstack.org, 12 (including one of our two largest core
> components: fuel-web) already have voting gate jobs, 3 more (including
> the other largest core component: fuel-library) have passing gate jobs
> that can become voting once all outstanding fixes are merged, and 3 more
> are a work in progress.
>
> Voting:
> - fuel-agent
> - fuel-dev-tools
> - fuel-devops
> - fuel-mirror
> - fuel-octane
> - fuel-ostf (pep8; python gates are waiting for images with gevent)
> - fuel-plugins
> - fuel-specs
> - fuel-stats
> - fuel-upgrade
> - fuel-web
> - python-fuelclient
>
> Ready to vote:
> - fuel-library (needs https://review.openstack.org/238628)
> - fuel-menu
> - shotgun
>
> Work in progress:
> - fuel-astute (has unit tests, needs a gate job)
> - fuel-docs (docs gate job is failing)
> - network-checker (unit test gate job is failing)
>
> Not covered by unit tests:
> - fuel-main (scripts to make Fuel ISO)
> - fuel-nailgun-agent (588 lines of Ruby)
> - fuel-qa (Fuel deployment system tests)
>
> While it might be a bit too early to pull out a "Mission Accomplished"
> banner, it's safe to say that vast majority of Fuel code is now covered
> by gate checks running unit tests and syntax checks on OpenStack CI.
>
> Nice work Alexey, Alex, Alexander, Sebastian, Vladimir, and Vladimir!
> Many thanks to the OpenStack Infra team for encouraging and supporting
> this effort!
>
> --
> Dmitry Borodaenko
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Stackalytics 0.9: new features and improvements

[Jay Pipes]

On 10/23/2015 05:26 AM, Ilya Shakhat wrote:

Hi all,

During the last month we've made a number of changes and improvements in
Stackalytics that deserve version tag and special announcement. The most
important feature is tracking history of official projects list - highly
demanded after shift to 'big tent' model.

The full list of changes below:

1. Stackalytics now respects history of changes in the official programs
list. Changes are tracked per-release, so if some project was accepted
officially in Liberty, it does not appear in the past and thus does not
affect Kilo stats. As anchor points we use tags in governance repo (e.g.
april-2015-elections)[1]
. These tags are
related to elections and created a bit before the release thus saving
from last-minute changes in the stats.

2. With removal of Stackforge, all projects are now classified in 2
groups: 'OpenStack' = listed in the official projects.yaml [2]

and 'OpenStack Others' = those that are in openstack organization, but
not accepted officially. As before, by default Stackalytics shows
official projects.

3. CI metric [3]  is redesigned from
scratch. Now it analyses votes in merged patches only, the numbers are
shown for every driver. List of drivers is synced with DriverLog [4]
.


4. Added a new driver status report [5]
. The report shows total
number of votes, success rate and the latest result per every driver per
module. The report is available for projects that have external CI
configured (Nova, Neutron, Cinder, Manila, Sahara, number of Fuel
plugins) The data may be not complete now and requires proper
configuration in DriverLog's default data (maintainers are welcome to
contribute into [4]
)

5. Abandoning a change request is now treated as reviewing [6]
 and is included into review
metric. Only abandoning of other's CRs is taken into account.

6. Reviews for own patches are not included into the stats anymore. In
the activity log such reviews are marked with prefix 'Self-' (e.g.
Self-Code-Review and Self-Approve)

7. Review processing is made compatible with Gerrit 2.9+, making
Stackalytics ready for infra upgrade.


Awesome work, Ilya, thanks for your work on these improvements.

Best,
-jay

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

Re: [openstack-dev] Dropping support for 3.2 in a bunch of upstream projects

[Flavio Percoco]

On 23/10/15 10:18 +1300, Robert Collins wrote:

Hi, so pip 8 is going to drop support for Python 3.2; setuptools 19
will drop support for it too.

This implies either pinning pip and setuptools in CI, or dropping
support for 3.2 in things where CI depends on those tools.

I know we don't specifically test or support 3.2 in OpenStack things
... but since we're a fairly big community of users of things I (help)
maintain, I thought I'd check and see whether folk here have a need
for 3.2 support - in higher level things.

So... I'm sending this email to poll for folk that *need* support for
3.2, to see how widespread the impact of dropping support would be.
(Obviously users can pin versions of the libraries that drop 3.2 - the
older releases will still be on PyPI... )

If there isn't a hue and cry about this then I think it will make
sense to drop support for Python 3.2 in mock, testtools, fixtures,
testrepository, testscenarios, testresources, unittest2, traceback2
and linecache2 - generally everything :)


+1 for dropping support for 3.2!

--
@flaper87
Flavio Percoco


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

[openstack-dev] [astara] Announcing the Astara Liberty release (formely Akanda)

[Adam Gandelman]

Hi All-

The Astara team is pleased to announce the availability of the Astara
Liberty release.  You can find a list of closed bugs, implemented
blueprints and release tarballs on launchpad at
https://launchpad.net/astara/+milestone/7.0.0.  We are proud of what we've
accomplished this release and look forward to another productive run during
the Mitaka cycle.

Our stable/liberty branches have been created and any critical bugs
discovered should be filed at http://bugs.launchpad.net/astara and brought
to developers attention with a 'backport-potential' tag.

It's worth noting here that we are in the process of renaming the project
from Akanda to Astara.  We are about halfway there at the moment, with
package names updated, console scripts and some code updated, but we
haven't completely renamed the code repositories.  We hope to get this
completed when we return from Tokyo and apologize in advance for any
confusion in the meantime.

Thanks and we hope to see many of you in Tokyo,
Adam
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

[Igor Kalnitsky]

Hi all,

> Just a small note, we shouldn't remove it completely from Nailgun
> codebase, because we still have old environments to support,

How many releases we should wait before nova-network completely?
AFAIK, it was deprecated since 6.1.. and it was kept in 7.0 only for
VCenter case. If so, maybe it's time to remove it completely in 8.0
and don't care for old environments? Otherwise, legacy code will never
be removed.

Igor.

On Thu, Oct 22, 2015 at 9:52 PM, Mike Scherbakov
 wrote:
> Hi all,
> I'm back to this thread. Who can take a lead here and remove nova-network
> starting from 8.0 and all following releases?
>
>
> On Thu, Oct 1, 2015 at 3:15 AM Sergii Golovatiuk 
> wrote:
>>
>> Hi,
>>
>> Can we get the latest supported release version? We will remove from
>> nailgun after End of Life of that particular release...
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Mike Scherbakov
> #mihgen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Fuel] Bugs status for ui, python and library. And 'area-*' tags.

[Vitaly Kramskikh]

Dmitry,

2015-10-22 21:42 GMT+07:00 Dmitry Pyzhov :

> Guys,
>
> 1) Bugs status
>
> Here is our current stats. Again I’ll show it in format “total (UI /
> python / library)"
>
> Critical and high bugs: 52 (6/28/18). Last week it was 46 (1/23/22)
> Medium, low and wishlist bugs: 196 (41/112/43). Last week it was 193
> (47/104/42)
> Features tracked as bug reports: 143. Last week we had 136. 111 are marked
> with ‘feature’ tag and 32 covered by blueprints. Last week it was 143 in
> total, 105 with 'feature' tag and 31 covered by blueprints.
> Technical debt bugs: 106 (2/80/24). Last week it was 101 (1/77/23) in
> total. Kinda huge and growing number. We’ve marked some of tech-debt bugs
> as High because we think them pretty important. There are 10 (0/6/4). Last
> week we had 9 (0/6/3)
>
> Not so inspiring numbers this week. We work hard both on fixing and
> reporting new bugs. It is about 15 new high priority defects reported every
> week. This is why second topic of my e-mail is important.
>
> 2) Area tags
> I'm analysing what's going on with our bugs and Launchpad is awful tool
> for bugs management. I've added new 'area' tags to all bugs in 8.0
> milestone. You probably know it from Launchpad e-mail reports (:smile:).
> I've tried to be as accurate as possible. We need these tags in order to
> measure our bugs status precisely. I hope we will add these tags to our
> triage process next week. Now you can try to use these tags and give some
> feedback if the idea is useful or not. Later we'll work on making following
> filters reliable.
>
> Python bugs: all
> 
> /open
> 
> (area-python tag)
> Library bugs: all
> 
> /open
> 
> (area-library tag)
> UI bugs: all
> 
> /open
> 
> (area-ui tag)
> Octane bugs: all
> 
> /open
> 
> (area-octane tag)
>
> Devops bugs: all
> 

Re: [openstack-dev] [Fuel] Changing APIs and API versioning

[Igor Kalnitsky]

Roman, Vitaly,

You're both saying right things, and you guys bring a sore topic up again.

The thing is that Nailgun's API isn't the best one.. but we're trying
to improve it step-by-step, from release to release. We have so many
things to reconsider and to fix that it'd require a huge effort to
make backward compatible changes and support it. So we decided ignore
backward compatibility for clients for awhile and consider our API as
unstable.

I agree with Roman that such changes must not be made secretly, and we
should at least announce about them. Moreover, every core must think
about consequences before approving them.

So I propose to do the following things when backward incompatible
change to API is required:

* Announce this change in openstack-dev ML.
* Wait 1 week before approving it, so anyone can prepare.
* Change author has to work with QA in order make sure they are
prepared for this change.

Any thoughts?

Thanks,
Igor

On Wed, Oct 21, 2015 at 5:24 PM, Vitaly Kramskikh
 wrote:
> JFYI: (re-)start of this discussion was instigated by merge of this change
> (and here is revert).
>
> And this is actually not the first time when we make backward incompatible
> changes in our API. AFAIR, the last time it was also about the network
> configuration handler. We decided not to consider our API frozen, make the
> changes and break backward compatibility. So now is the time to reconsider
> this.
>
> API backward compatibility is a must for good software, but we also need to
> understand that introducing API versioning is not that easy and will
> increase efforts needed to make new changes in nailgun.
>
> I'd go this way:
>
> Estimate the priority of introducing API versioning - maybe we have other
> things we should invest our resources to
> Estimate all the disadvantages this decision might have
> Fix all the issues in the current API (like this one)
> Implement API versioning support (yes, we don't have this mechanism yet, so
> we can't just "bump API version" like Sergii suggested in another thread)
> Consider the current API as frozen v1, so backward incompatible changes (or
> maybe all the changes?) should go to v2
>
>
> 2015-10-21 20:25 GMT+07:00 Roman Prykhodchenko :
>>
>> Hi folks,
>>
>> I’d like to touch the aspect of Fuel development process that seems to be
>> as wrong as possible. That aspect is how we change the API.
>>
>> The issue is that in Fuel anyone can change API at any point of time
>> without even warning the rest of the same component’s team. Relying on this
>> kind of API is basically impossible. We constantly have problems when even
>> components of Fuel stop working due to unexpected changes in the API.
>> Thinking about another software that must be integrated with Fuel is hardly
>> possible with the current approach.
>>
>> As for a grown-up project there is a strong need for Fuel in general and
>> for Nailgun in particular to work on a policy for making changes to their
>> APIs. Living in OpenStack ecosystem we must at least take a look how it’s
>> done in its components and try to do something similar. After working with
>> Nova, Keystone, Ironic and other components I would propose to start with
>> the following: let’s not make any changes to the API. Instead, let’s create
>> a new version of Nailgun’s API that will appear in Fuel 8.0 and make all the
>> changes there. That is the thing that will instantaneously make lives of
>> other components much easier, if we make it now.
>>
>> After doing the essential part let’s think about how we are going to live
>> with that in the future. There are several APIs in Fuel, the rest of the
>> email is only touching Nailgun’s REST API. I can see the things somehow like
>> the following:
>>
>>  - Introduce API documentation by embedding Swagger and Swagger UI.
>>The current approach when we leave API docs for documentation team is
>> not effective. Swagger generates the documentation and resolves this issue.
>>  - After releasing a version of Fuel, it’s API is called stable and frozen
>> for any changes, unless they allign API to the documentation or
>> documentation to the API.
>>  - All changes to a stable APIs must be backported to the stable version
>> of Fuel that introduced the corresponding API.
>>  - In order to guarantee that a stable API is not changed, Jenkins jobs
>> should make automatic checks for every new patch set
>>
>> Details about all the above mentioned proposals can be discussed in
>> separate threads so this one will stay uncluttered. I'd like to also summon
>> those OpenStack folks, who tried to resolve the same issue and ask them
>> about any common solutions in the ecosystem.
>>
>>
>> - romcheg
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --

[openstack-dev] Stackalytics 0.9: new features and improvements

[Ilya Shakhat]

Hi all,

During the last month we've made a number of changes and improvements in
Stackalytics that deserve version tag and special announcement. The most
important feature is tracking history of official projects list - highly
demanded after shift to 'big tent' model.

The full list of changes below:

1. Stackalytics now respects history of changes in the official programs
list. Changes are tracked per-release, so if some project was accepted
officially in Liberty, it does not appear in the past and thus does not
affect Kilo stats. As anchor points we use tags in governance repo (e.g.
april-2015-elections)[1]
. These tags are
related to elections and created a bit before the release thus saving from
last-minute changes in the stats.

2. With removal of Stackforge, all projects are now classified in 2 groups:
'OpenStack' = listed in the official projects.yaml [2]

and 'OpenStack Others' = those that are in openstack organization, but not
accepted officially. As before, by default Stackalytics shows official
projects.

3. CI metric [3]  is redesigned from
scratch. Now it analyses votes in merged patches only, the numbers are
shown for every driver. List of drivers is synced with DriverLog [4]

.

4. Added a new driver status report [5]
. The report shows total number
of votes, success rate and the latest result per every driver per module.
The report is available for projects that have external CI configured
(Nova, Neutron, Cinder, Manila, Sahara, number of Fuel plugins) The data
may be not complete now and requires proper configuration in DriverLog's
default data (maintainers are welcome to contribute into [4]

)

5. Abandoning a change request is now treated as reviewing [6]
 and is included into review
metric. Only abandoning of other's CRs is taken into account.

6. Reviews for own patches are not included into the stats anymore. In the
activity log such reviews are marked with prefix 'Self-' (e.g.
Self-Code-Review and Self-Approve)

7. Review processing is made compatible with Gerrit 2.9+, making
Stackalytics ready for infra upgrade.

Thanks,
Ilya

[1] - https://git.openstack.org/cgit/openstack/governance/
[2] -
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[3] - http://stackalytics.com/?metric=ci
[4] -
http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
[5] - http://stackalytics.com/report/ci/cinder/7
[6] - https://bugs.launchpad.net/bugs/1498769
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Integrating kollacli as python-kollaclient

[Harm Weites]

+1 this sort of stuff makes live a lot better :)

Swapnil Kulkarni schreef op 2015-10-23 07:08:

On Thu, Oct 22, 2015 at 3:50 AM, Steven Dake (stdake)
 wrote:


Hello Folks,

Oracle has developed a CLI tool for managing OpenStack Kolla
clusters.  Several months ago at our midcycle, the topic was
brought up an I suggested to go ahead and get started on the work. 
We clearly didn't spend enough time discussing how it should be
integrated into the code base or developed or even what its features
should be, and that is my error.

What ended up happening is sort of a code dump, which is not ideal,
but I can only work so many 20 hour days ;)  I didn't believe our
community had the bandwidth to deal with integrating a CLI directly
into the tree while we were focused on our major objective of
implementing Ansible deployment of OpenStack in Docker containers. 
Possibly the wrong call, but it is what it is and it is my error,
not Oracles.


I think user experience will of the one of the major milestones for
Kolla in Mitaka, e.g. user facing documentation, operator integration
etc. a CLI would be helpful in that.


The code can be cloned from:

git clone git://oss.oracle.com/git/openstack-kollacli.git [1]

The code as is is very high quality but will likely need to go
through alot of refactoring to ReST-ify it.  There are two major
authors of the code, Borne Mace and Steve Noyes.

I'd like a majority vote from the core team as to whether we should
add this repository to our list of governed repositories in the
OpenStack Kolla governance repository here:














hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509

[2]

Consider this email a +1 vote from me.


+1 from me 


A completely separate email thread and decision will be made by the
community about core team membership changes to handle maintenance
of the code.  Assuming this code is voted into Kolla's governance,
I plan to propose Borne as a core reviewer, which will be open to
core team vote as a separate act with our 3 +1 votes no vetos within
1 week period.  We will address that assuming a majority vote of
the code merge wins.  Steve can follow the normal processes for
joining the core team if he wishes (reviewing patches) - clearly his
code contributions are there.  Borne already does some reviews, and
although he isn't a top reviewer, he does have some contribution in
this area making it into the top 10 for the Liberty cycle.

 



Kolla CLI Features:

* dynamic ansible inventory manipulation via the host, group and
service commands
* ssh key push via the host setup command
* ssh key validation via the host check command
* ansible deployment via the deploy command
* property viewing and modification with the property list, set and
clear commands
* cleanup of docker containers on a single, multiple or all hosts
via the host destroy command
* debug data collection via the dump command
* configuration of openstack passwords via the password command
* Lines of python = 2700
* Lines of  test case code =  1800
* ~ 200 commits


 
 
 
___

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




Links:
--
[1] http://oss.oracle.com/git/openstack-kollacli.git
[2]











hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509
[3] 
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 
 
___

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [HA][RabbitMQ][messaging][Pacemaker][operators] Improved OCF resource agent for dynamic active-active mirrored clustering

[Bogdan Dobrelya]

Hello.
I'm glad to announce that the pacemaker OCF resource agent for the
rabbitmq clustering, which was born in the Fuel project initially, now
available and maintained upstream! It will be shipped with the
rabbitmq-server 3.5.7 package (release by November, 2015)

You can read about this OCF agent in the official guide [0] (flow charts
for promote/demote/start/stop actions in progress).

And you can try it as a tiny cluster example with a Vagrant box for
Atlas [1]. Note, this only installs an Ubuntu box with a
Corosync/Pacemaker & RabbitMQ clusters running, no Fuel or OpenStack
required :-)

I'm also planning to refer this official RabbitMQ cluster setup guide in
the OpenStack HA guide as well [2].

PS. Original rabbitmq-users mail thread is here [3].
[openstack-operators] cross posted as well.

[0] http://www.rabbitmq.com/pacemaker.html
[1] https://atlas.hashicorp.com/bogdando/boxes/rabbitmq-cluster-ocf
[2] https://bugs.launchpad.net/openstack-manuals/+bug/1497528
[3] https://groups.google.com/forum/#!topic/rabbitmq-users/BnoIQJb34Ao

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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