date:20151204


On 12/03/2015 08:45 PM, Tzu-Mainn Chen wrote:

Hey all,

Over the past few months, there's been a lot of discussion and work around
creating a new REST API-supported TripleO deployment workflow.  However most
of that discussion has been fragmented within spec reviews and weekly IRC
meetings, so I thought it might make sense to provide a high-level overview
of what's been going on.  Hopefully it'll provide some useful perspective for
those that are curious!

Thanks,
Tzu-Mainn Chen

--
1. Explanation for Deployment Workflow Change

TripleO uses Heat to deploy clouds.  Heat allows tremendous flexibility at the
cost of enormous complexity.  Fortunately TripleO has the space to allow
developers to create tools to simplify the process tremendously,  resulting in
a deployment process that is both simple and flexible to user needs.

The current CLI-based TripleO workflow asks the deployer to modify a base set
of Heat environment files directly before calling Heat's stack-create command.
This requires much knowledge and precision, and is a process prone to error.

However this process can be eased by understanding that there is a pattern to
these modifications; for example, if a deployer wishes to enable network
isolation, a specific set of modifications must be made.  These  modification
sets can be encapsulated through pre-created Heat environment files, and TripleO
contains a library of these
(https://github.com/openstack/tripleo-heat-templates/tree/master/environments).

These environments are further categorized through the proposed environment
capabilities map (https://review.openstack.org/#/c/242439).  This mapping file
contains programmatic metadata, adding items such as user-friendly text around
environment files and marking certain environments as mutually exclusive.


2. Summary of Updated Deployment Workflow

Here's a summary of the updated TripleO deployment workflow.

 1. Create a Plan: Upload a base set of heat templates and environment files
into a Swift container.  This Swift container will be versioned to allow
for future work with respect to updates and upgrades.

 2. Environment Selection: Select the appropriate environment files for your
deployment.

 3. Modify Parameters: Modify additional deployment parameters.  These
parameters are influenced by the environment selection in step 2.

 4. Deploy: Send the contents of the plan's Swift container to Heat for
deployment.

Note that the current CLI-based workflow still fits here: a deployer can modify
Heat files directly prior to step 1, follow step 1, and then skip directly to
step 4.  This also allows for trial deployments with test configurations.


3. TripleO Python Library, REST API, and GUI

Right now, much of the existing TripleO deployment logic lives within the 
TripleO
CLI code, making it inaccessible to non-Python based UIs.   Putting both old and
new deployment logic into tripleo-common and then creating a REST API on top of
that logic will enable modern Javascript-based GUIs to create cloud deployments
using TripleO.


4. Future Work - Validations

A possible next step is to add validations to the TripleO toolkit: scripts that
can be used to check the validity of your deployment pre-, in-, and  
post-flight.
These validations will be runnable and queryable through a  REST API.  Note that
the above deployment workflow should not be a requirement for validations to be
run.


5. In-Progress Development

The initial spec for the tripleo-common library has already been approved, and
various people have been pushing work forward.  Here's a summary:

* Move shared business logic out of CLI
   * https://review.openstack.org/249134 - simple validations (WIP)


When is this going to be finished? It's going to get me a huge merge 
conflict in https://review.openstack.org/#/c/250405/ (and make it 
impossible to backport to liberty btw).



   * https://review.openstack.org/228991 - deployment code (ready for review)

* Additional TripleO business logic
   * rename tripleo-common repo to tripleo
 * https://review.openstack.org/#/c/249521/ (ready for review)
 * https://review.openstack.org/#/c/249524/ (ready for review)
 * https://review.openstack.org/#/c/247834/ (ready for review)
   * https://review.openstack.org/#/c/242439 - capabilities map (ready for 
review)
   * https://review.openstack.org/#/c/227297/ - base tripleo library code 
(ready for review)
   * https://review.openstack.org/#/c/232534/ - utility functions to manage 
environments (ready for review)
   * after the above is merged, plan.py will need to be updated to include 
environment methods

* TripleO API
   * https://review.openstack.org/#/c/230432/ - API spec (ready for review)
   * https://review.openstack.org/#/c/243737/  - API (WIP)
   * after the library code is fully merged, API will need to be updated to 
allow access
 to a

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

2015-12-04 Thread Nikolay Starodubtsev

+1



Nikolay Starodubtsev

Software Engineer

Mirantis Inc.


Skype: dark_harlequine1

2015-12-04 12:46 GMT+03:00 Dina Belova :

> Dear performance folks,
>
> There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> ) to
> 16:00 UTC (also Tuesdays
> ) to
> make them more comfortable for US guys.
>
> Please leave your +1 / -1 here in the email thread.
>
> Btw +1 from me :)
>
> Cheers,
> Dina
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

2015-12-04 Thread Dina Belova

Dear performance folks,

There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
) to
16:00 UTC (also Tuesdays
) to
make them more comfortable for US guys.

Please leave your +1 / -1 here in the email thread.

Btw +1 from me :)

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

Re: [openstack-dev] [ironic] specs process for ironic-inspector


On 12/03/2015 06:13 PM, Pavlo Shchelokovskyy wrote:

Hi Dmitry,

should we also configure Launchpad to have blueprints references there
(for release/milestone targeting etc)? Or is it not needed?


Not sure what you mean, we do have Launchpad configured for blueprints. 
We used and will continue to use it for tracking features. Now some more 
complex blueprints will need a spec in addition. Does it answer your 
question?




Cheers,

On Thu, Dec 3, 2015 at 4:00 PM Dmitry Tantsur > wrote:

FYI: the process is in effect now.

Please submit specs to
https://github.com/openstack/ironic-inspector-specs/
Approved specs will appear on
http://specs.openstack.org/openstack/ironic-inspector-specs/

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


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




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

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

2015-12-04 Thread Kuvaja, Erno

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Wednesday, December 02, 2015 8:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> [Apologies for the delayed reply, after more than a week without Internet
> access it's taking me more than a week to catch up with everything on the
> mailing lists.]
> 
> On 2015-11-20 10:21:47 + (+), Kuvaja, Erno wrote:
> [...]
> > So we were brainstorming this with Rocky the other night. Would this
> > be possible to do by following:
> >
> > 1) we still tag juno EOL in few days time
> 
> Hopefully by the end of this week, once I finish making sure I'm up to speed
> on everything that's been said while I was out (anything less would be
> irresponsible of me).
> 
> > 2) we do not remove the stable/juno branch
> 
> As pointed out later in this thread by Alan, it's technically possible to use 
> a tag
> instead of a branch name (after all, both are just Git refs in the end), and
> deleting the branch sends a clearer message that there are no new commits
> coming for stable/juno ever again.
> 
> > 3) we run periodic grenade jobs for kilo
> >
> > I'm not that familiar with the grenade job itself so I'm doing couple
> > of assumptions, please correct me if I'm wrong.
> >
> > 1) We could do this with py27 only
> 
> Our Grenade jobs are only using Python 2.7 anyway.
> 
> > 2) We could do this with Ubuntu 1404 only
> 
> That's the only place we run Grenade now that stable/icehouse is EOL (it was
> the last branch for which we supported Ubuntu 12.04).
> 
> > If this is doable would we need anything special for these jobs in
> > infra point of view or can we just schedule these jobs from the pool
> > running our other jobs as well?
> >
> > If so is there still "quiet" slots on the infra utilization so that we
> > would not be needing extra resources poured in for this?
> >
> > Is there something else we would need to consider in QA/infra point of
> > view?
> [...]
> 
> There are no technical Infra-side blockers to changing how we've done this in
> the past and instead continuing to run stable/kilo Grenade jobs for some
> indeterminate period after stable/juno is dead, but it's also not (entirely) 
> up
> to Infra to decide this. I defer to the Grenade maintainers and QA team to
> make this determination, and they seem to be pretty heavily against the
> idea.
> 
> > Big question ref the 2), what can we do if the grenade starts failing?
> > In theory we won't be merging anything to kilo that _should_ cause
> > this and we definitely will not be merging anything to Juno to fix
> > these issues anymore. How much maintenance those grenade jobs
> > themselves needs?
> 
> That's the kicker. As I explained earlier in the thread from which this one
> split, keeping Juno-era DevStack and Tempest and all the bits on which they
> rely working in our CI without being able to make any modifications to them
> is intractable (mainly because of the potential for behavior changes in
> transitive dependencies not under our control):
> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-
> December/081109.html
> 
> > So all in all, is the cost doing above too much to get indicator that
> > tells us when Juno --> Kilo upgrade is not doable anymore?
> 
> Yes. This is how we arrived at the EOL timeline for stable/juno in the first
> place: gauging our ability to keep running things like DevStack and Tempest
> on it. Now is not the time to discuss how we can keep Juno on some
> semblance of life support (that discussion concluded more than a year ago),
> it's time for discussing what we can implement in Mitaka so we have more
> reasonable options for keeping the stable/mitaka branch healthy a year from
> now.
> --
> Jeremy Stanley

Thanks for two detailed reply Jeremy!

I think this (and the one you replied to Rocky) gives enough background in 
compact package for interested parties to start focusing their efforts to the 
direction they seem appropriate. Let's see where we are in a year's time.

- Erno

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

Re: [openstack-dev] [midonet] IRC: ditch #midonet-dev?

2015-12-04 Thread Sandro Mathys

On Wed, Dec 2, 2015 at 5:55 PM, Jan Hilberath  wrote:
> On 2015年12月01日 19:14, Takashi Yamamoto wrote:
>>
>> On Tue, Dec 1, 2015 at 7:08 PM, Antoni Segura Puimedon
>>  wrote:
>>>
>>>
>>>
>>> On Tue, Dec 1, 2015 at 10:59 AM, Ivan Kelly  wrote:


 +1 for #2
>>>
>>>
>>>
>>> PS: Beware of the top-posting! It makes vote counting harder ;-)
>>>


 On Tue, Dec 1, 2015 at 10:57 AM, Sandro Mathys 
 wrote:
>
> Hi,
>
> Our IRC channels have been neglected for a long time, and as a result
> we lost ownership of #midonet-dev, which is now owner by
> freenode-staff. In theory, it should be very easy to get ownership
> back, particularly since we still own #midonet. But in reality, it
> seems like none of the freenode staff feel responsible for these
> requests, so we still aren't owners after requesting it for 3 weeks
> already.
>
> Therefore, Toni Segura suggested we just ditch it and move to
> #openstack-midonet instead.
>
> However, several people have also said we don't need two channels,
> i.e. we should merge #midonet and #midonet-dev.
>
> So, here's three proposals:
>
> Proposal #1:
> * keep #midonet
> * replace #midonet-dev with #openstack-midonet
>
> Proposal #2:
> * keep #midonet
> * merge #midonet-dev into #midonet
>>>
>>>
>>>
>>> +1
>>
>>
>> +1
>
>
> +1

Alright, we'll go with #midonet then. I've now configured #midonet-dev
so, that anyone who tries to join it is instead forwarded to #midonet.
I've also set up the same for #openstack-midonet, just in case someone
is looking for us there.

I've also archived all developers' channels on Slack with a note that
we moved to IRC.

Cheers,
Sandro

>>
>>>

>
> Proposal #3:
> * replace both #midonet and #midonet-dev with #openstack-midonet
>
> I don't have any strong feelings for any of the proposals, but suggest
> we go with proposal #2. Traffic in both #midonet and #midonet-dev is
> rather low, so one channel should do - there's way busier OpenStack
> channels out there. Furthermore, #midonet is shorter than
> #openstack-midonet and already established. I also think people will
> rather look in #midonet than #openstack-midonet if they're looking for
> us.
>
> Thoughts?
>
> Cheers,
> Sandro
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

[openstack-dev] [all][infra] All tox jobs broken, don't approve changes for now

2015-12-04 Thread Andreas Jaeger

Currently all tox jobs are broken in the OpenStack CI. The infra-team is 
fixing this right now.


Please do not approve any changes until the broken patch has been 
reverted and all tox jobs have been updated, we'll send an email once 
this is done,


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


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

Re: [openstack-dev] [Manila] Tempest scenario tests vs. gate condition

2015-12-04 Thread Valeriy Ponomaryov

Hello John,

If I am not mistaken, none of existing Third-Party CIs run scenario tests.
So, it can not be the blocker for you. It is true to say that, for the
moment, API tests is enough for Third-Party CI.

Regards,
Valeriy Ponomaryov

On Thu, Dec 3, 2015 at 1:38 PM, John Spray  wrote:

> Hi,
>
> We're working towards getting the devstack/CI parts ready to test the
> forthcoming ceph native driver, and have a question: will a driver be
> accepted into the tree if it has CI for running the api/ tempest
> tests, but not the scenario/ tempest tests?
>
> The context is that because the scenario tests require a client to
> mount the shares, that's a bit more work for a new protocol such as
> cephfs.  Naturally we intend to do get that done, but would like to
> know if it will be a blocker in getting the driver in tree.
>
> Many thanks,
> John
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] making project_id optional in API URLs

2015-12-04 Thread Valeriy Ponomaryov

Manila uses "project_id"s in URLs as Cinder does. So, the same amount of
work for each of projects is required.

On Fri, Dec 4, 2015 at 3:29 AM, Jim Rollenhagen 
wrote:

>
> > On Dec 3, 2015, at 12:06, Sean Dague  wrote:
> >
> > For folks that don't know, we've got an effort under way to look at some
> > of what's happened with the service catalogue, how it's organically
> grown,
> > and do some pruning and tuning to make sure it's going to support what
> > we want to do with OpenStack for the next 5 years (wiki page to dive
> > deeper here - https://wiki.openstack.org/wiki/ServiceCatalogTNG).
> >
> > One of the items which came up is removing project_id from API urls.
> > Today there is a very odd linkage between keystone service catalog
> > entries and project_ids. For instance in Nova every single project has a
> > different API endpoint.
> >
> > https://nova.api.server/v2.1/$project_id
> >
> > That has implications for caching, and exposing this anonymously, and
> > having to carry around the whole service catalog in your oslo.context
> > (which means putting it over the RPC bus a lot).
> >
> > For Nova, this was almost entirely ignored. It turned out to be a pretty
> > simple functional change to have a set of routes which don't need them -
> > https://review.openstack.org/#/c/233076/6  (it's more involved to have
> > comprehensive testing, but we'll ignore that for now).
> >
> > Projects that spawned from Nova: Cinder, Glance, Ironic, Manila, Magnum,
> > I'm hoping this is just as much of a surface integration that optionally
> > dropping it shouldn't be a big deal. However, for any projects that have
> > it, if folks could speak up, that would be great. It would also be good
> > to know which projects are up for making this kind of change this cycle,
> > as certain future work is inhibited until we get this in. We'll be
> > landing this in Nova this cycle.
> >
> > Swift is a different story, the project_id is a core concept in the
> > resources. That's fine, but when we expose a new resource for the
> > service catalog tng, we won't be doing the magic substitution on the
> > server side. New clients, consuming the new interface, will need to
> > construct the urls themselves.
> >
> > So, for Cinder, Glance, Ironic, Manila, Magnum (and others I might have
> > missed) where are you standing on this one? And are there volunteers in
> > those projects to help move this forward?
>
> Ironic today has no concept of tenant/project/etc so should be nothing to
> do here. :)
>
> // jim
>
> >
> >-Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] [release] New Mitaka release schedule page

Hi everyone,

As part of the effort to move reference information off the wiki to a
more peer-reviewable area, the Mitaka release schedule page was moved to:

http://docs.openstack.org/releases/schedules/mitaka.html

One side benefit is that projects can propose and add their own
deadlines (think spec submission deadline, early feature freezes, etc.)
to this page by proposing changes to the doc/source/schedules/mitaka.rst
file in the openstack/releases git repository:

http://git.openstack.org/cgit/openstack/releases/tree/doc/source/schedules/mitaka.rst

Ideally that way it will turn into a clear list of all development
deadlines in a given development cycle, making it easier to keep track
of everything.

Please help by adding your own project information to this page!
Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [horizon]

2015-12-04 Thread Lin Hua Cheng

The most efficient way to do this for Swift to do this is to implement Form
Post[1] (upload) and tempUrl[2] (download). With this setup, the user will
be directly uploading/downloading from Swift endpoint rather than passing
the files through horizon.

The caveat for this to work, you need to be able to associate access keys
to users.

-Lin

[1] http://docs.openstack.org/developer/swift/api/form_post_middleware.html
[2]
http://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html

On Thu, Dec 3, 2015 at 3:20 PM, Kyrylo Galanov 
wrote:

> Hello,
>
> When a file is uploaded to Glance, Swift through Horizon it is stored
> locally in a temporary directory in Horizon server. This is inefficient
> approach especially for big files.
>
> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
> buffer instead of storing a file locally. It would eliminate such drawbacks
> as potential free space exhaustion.
>
> It would be awesome to add upload progress bar as well.
>
> I look forward to your constructive replies.
>
> Best regards,
> Kyrylo
>
> __
> OpenStack Development Mailing 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] Documentation containing external resource links & privacy breaches

2015-12-04 Thread Cory Benfield

> On 4 Dec 2015, at 10:06, Thomas Goirand  wrote:
> 
> That's actually a very good idea, I didn't think it was possible. Could
> you explain a bit more how this kind of patch would look like?

Sure. Rather than explain and take the credit, I’ll point you directly at the 
code in the Alabaster[0] repository that controls this and from where I 
‘borrowed’ the idea.

Here[1] is the code in the Alabaster ‘layout.html’ file that optionally 
includes the GA tracking script. Per the README[2], you can then set 
html_theme_options = {‘analytics_id’: }, which will cause the GA 
tracking script to be included with the appropriate ID.

I’m not exactly sure where the OpenStack theme lives, but assuming it’s the one 
in oslosphinx/theme/openstack, then you’d add the appropriate conditional 
template block here[3], probably with a default value in this file[4].

If this seems like something that’s generally desired, I’m open to making the 
actual patch to oslosphinx (or wherever the actual theme is mastered) myself.

Cory

[0]: https://github.com/bitprophet/alabaster
[1]: 
https://github.com/bitprophet/alabaster/blob/49f1bfec244609ab1a47592087342725163a2e88/alabaster/layout.html#L36-L52
[2]: 
https://github.com/bitprophet/alabaster/blob/49f1bfec244609ab1a47592087342725163a2e88/README.rst#theme-options
[3]: 
https://github.com/openstack/oslosphinx/blob/f8d71ac5ad023a32cbbe04e109eb2793433ee558/oslosphinx/theme/openstack/layout.html#L97-L108
[4]: 
https://github.com/openstack/oslosphinx/blob/f8d71ac5ad023a32cbbe04e109eb2793433ee558/oslosphinx/theme/openstack/theme.conf

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

[Openstack-operators] Migrate ephemeral nodes

2015-12-04 Thread Davíð Örn Jóhannsson

Is it possible to migrate ephemeral volumes from their default location to an 
ephemeral LVM volume?


The reason for this is that we just added additional storage to the servers and 
created a volume group that we want to use as a backend for ephemeral storage 
on the compute hosts and are searching for ways to move instances to that 
without having to delete and re-create instances currently using 
/var/lib/nova/instances as backend for epithermal storage.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [ironic] specs process for ironic-inspector

2015-12-04 Thread Pavlo Shchelokovskyy

Oh, I just found it. Sorry for bothering.

Cheers,

On Fri, Dec 4, 2015 at 12:03 PM Dmitry Tantsur  wrote:

> On 12/03/2015 06:13 PM, Pavlo Shchelokovskyy wrote:
> > Hi Dmitry,
> >
> > should we also configure Launchpad to have blueprints references there
> > (for release/milestone targeting etc)? Or is it not needed?
>
> Not sure what you mean, we do have Launchpad configured for blueprints.
> We used and will continue to use it for tracking features. Now some more
> complex blueprints will need a spec in addition. Does it answer your
> question?
>
> >
> > Cheers,
> >
> > On Thu, Dec 3, 2015 at 4:00 PM Dmitry Tantsur  > > wrote:
> >
> > FYI: the process is in effect now.
> >
> > Please submit specs to
> > https://github.com/openstack/ironic-inspector-specs/
> > Approved specs will appear on
> > http://specs.openstack.org/openstack/ironic-inspector-specs/
> >
> > --
> > Dr. Pavlo Shchelokovskyy
> > Senior Software Engineer
> > Mirantis Inc
> > www.mirantis.com
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][DVR]

2015-12-04 Thread Oleg Bondarev

On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) <
swaminathan.vasude...@hpe.com> wrote:

> Hi Carl,
> Sounds reasonable suggestion.
> Thanks
> Swami
>
> -Original Message-
> From: Carl Baldwin [mailto:c...@ecbaldwin.net]
> Sent: Thursday, December 03, 2015 10:47 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Neutron][DVR]
>
> I was going to bring this up in the meeting this morning but IRC troubles
> prevented it.
>
> After chatting with Armando, I'd like to suggest a few enhancements to how
> we're tackling DVR during this cycle.  I'm hoping that these changes help
> us to get things done faster and more efficiently.  Let me know if you
> think otherwise.
>
> First, I'd like to suggest adding DvrImpact to the comment of any patches
> that are meant to improve DVR in some way.  People have asked me about
> reviewing DVR changes.  I can show them the DVR backlog [1] in launchpad
> but it would be nice to have a DVR specific dashboard.
> With DvrImpact in the subject, we can make it even more convenient to find
> reviews.
>

+1


>
> The other change I'd like to propose is to categorize our DVR backlog in
> to three categories:  broken, scale (loadimpact), and new features.
> I'd propose that we prioritize in that order.  Anyone have any suggestions
> for how to tag or otherwise categorize and tackle these?
>

This might be useful but honestly I don't feel a strong need for
categorizing dvr bugs at the moment because of the amount of bugs
(currently I see 31 when filtering by l3-dvr-backlog tag).
l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-backlog +
loadimpact for 'scale', l3-dvr-backlog + Wishlist for new (small)
enhancements.
I might be missing something though.


> I know there is a loadimpact (or similar) tag those.  Should we come up
> with a couple more tags to divide the rest?
>
> Thoughts?
>
> Carl
>
> [1] https://goo.gl/M5SwfS
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] FFE for Ubuntu bootstrap

2015-12-04 Thread Mike Scherbakov

Dmitry,
thank you for clarification of a status. In a meeting we had [1], I
misinterpreted a status of a feature is being fully completed, and that is
what I reflected in my FFEs post [2].

I'm not sure if we have definition of done written for Fuel specifically,
but my expectation from the spec [3] was that Ubuntu bootstrap has to be
default option. That means that all related code has to be merged.
One of the patches you've mentioned goes on since November, 27 and I'm not
sure how long would it take to complete it. It is not a simple switch in a
config file as I'd expect to see.
It's not a 100+ LOC changeset in very core either, so I call for Matt as a
maintainer [4] and core reviewers to assess a situation.

My perspective is that we can test it right now without this patch and
steps to do so are known [6], so feature is actually nearly complete except
of additional action in fuel-menu. I hope that we could go an extra mile
here and maintainer / cores could help with the patch.

I don't personally think that we could go on without having a clear
deadline for when it will be enabled. Even if [4] is merged, but ubuntu is
not a default - I see a serious risks here, as majority of our automated
tests and lots of manual tests done by random people will still be using
another image, thus significantly decreasing our chances to see regressions
on time.

I'd give it an exception till end of Tuesday (as of after CentOS 7 expected
merges) for full enablement, and that should have a fix to critical issue
[7].

[1] https://etherpad.openstack.org/p/fuel-8.0-FF-meeting
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html
[3]
http://specs.fuel-infra.org/fuel-specs-master/specs/8.0/dynamically-build-bootstrap.html
[4] https://review.openstack.org/#/c/250662/
[5] https://github.com/openstack/fuel-menu/blob/master/MAINTAINERS
[6] https://bugs.launchpad.net/fuel/+bug/1522406/comments/3
[7] https://bugs.launchpad.net/fuel/+bug/1522406

On Thu, Dec 3, 2015 at 10:59 AM Dmitry Klenov  wrote:

> Hi folks,
>
> Let me clarify the situation with Ubuntu bootstrap feature.
>
> First of all, I would like to highlight that all functional commits for
> this feature were merged. This means that starting from yesterday everyone
> has an ability to switch to Ubuntu-based bootstrap manually and start using
> it. So I do not see the risk in loosing testing cycles in the community.
>
> The item which brought concerns on today status meeting was the enablement
> of the feature by default. To do it, 2 patches have to be merged together:
> * https://review.openstack.org/#/c/250662/ - main switch.
> * https://review.openstack.org/#/c/251908/ - compatibility commit to QA
> suite to comply with new bootstrap config format.
>
> I would like to raise the question if we can have a feature freeze
> exception for these 2 patches?
>
> There are a couple of reasons why I consider it safer to merge these
> patches several days later:
> * There is a bug caught today which will block the tests to pass if we
> switch to Ubuntu bootstrap by default:
> https://bugs.launchpad.net/fuel/+bug/1522406
> * There were concerns that a lot of FF commit merges can bring instability
> to QA suite. So it might be reasonable not to bring one more variable right
> now and to enable ubuntu bootstrap by default when all automated tests are
> stabilized.
>
> I would like to ask engineering and QA leads to express their ideas on
> this.
>
> Thanks,
> Dmitry.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] [Nova] [Glance] Errors Produced by Nova and Glance Interaction

2015-12-04 Thread Ivan Derbenev

Looks like this is your issue
https://bugs.launchpad.net/glance/+bug/1476770

Regards,
IT engineer
Farheap, Russia
Ivan Derbenev

From: Richard Raseley [mailto:rich...@raseley.com]
Sent: Friday, December 4, 2015 5:50 AM
To: openstack@lists.openstack.org
Subject: [Openstack] [Nova] [Glance] Errors Produced by Nova and Glance 
Interaction

I am running OpenStack Juno installed from RDO packages, all version 
2015.1.1-1.el7, on CentOS 7.

I am experiencing an issue whenever Nova has to interact with Glance wherein it 
is unable to do anything other than retrieve the list of available images. Here 
is an example:

```

(openstack)➜  openstack  glance image-list
+--+-+
| ID   | Name|
+--+-+
| 70bcde32-dcfc-47f6-8596-9d968fae2011 | cirros-0.3.4-x86_64 |
+--+-+

(openstack)➜  openstack  glance image-show 70bcde32-dcfc-47f6-8596-9d968fae2011
+--+--+
| Property | Value|
+--+--+
| architecture | x86_64   |
| checksum | ee1eca47dc88f4879d8a229cc70a07c6 |
| container_format | bare |
| created_at   | 2015-12-03T15:10:22Z |
| description  | CirrOS 0.3.4 x86_64  |
| disk_format  | qcow2|
| id   | 70bcde32-dcfc-47f6-8596-9d968fae2011 |
| min_disk | 1|
| min_ram  | 512  |
| name | cirros-0.3.4-x86_64  |
| owner| bd712506c2ba41f2b1d661f97c927f8a |
| protected| False|
| size | 13287936 |
| status   | active   |
| tags | []   |
| updated_at   | 2015-12-03T15:10:26Z |
| virtual_size | None |
| visibility   | private  |
+--+--+

(openstack)➜  openstack  nova image-list
+--+-+++
| ID   | Name| Status | Server |
+--+-+++
| 70bcde32-dcfc-47f6-8596-9d968fae2011 | cirros-0.3.4-x86_64 | ACTIVE ||
+--+-+++

(openstack)➜  openstack  nova image-show 70bcde32-dcfc-47f6-8596-9d968fae2011
ERROR (ClientException): The server has either erred or is incapable of 
performing the requested operation. (HTTP 500) (Request-ID: 
req-f27a5253-dc65-4689-9d89-f80ddc873e37)

```

This is causing the inability to launch instances. Whenever this occurs, the 
Glance API logs look clean and I see a 200 response to each request, however 
the Nova API logs show an ‘AttributeError’ 
(http://paste.openstack.org/show/480853/) for each request. I had originally 
thought this was related to this bug 
(https://bugs.launchpad.net/glance/+bug/1476770), but am still experiencing it 
with keystonemiddleware 1.5.3, requests 2.8.1, and urllib3 1.12.

Any assistance would be greatly appreciated, as this is currently a blocking 
issue for me.

Regards,

Richard

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

Re: [openstack-dev] [glance] Auth_version from 'old style' URLs in the database

2015-12-04 Thread Flavio Percoco


On 03/12/15 16:24 +, Bunting, Niall wrote:

Hi,

Currently glance will use an auth_url if in the database. Eg. 10.0.0.8:5000/v2.0

However glance currently takes the auth_version from the config
files. Therefore this can lead to a mismatch of keystone version to be used
between the url and the config files. This is problematic due to a different
resource id being required in different version of keystone (in keystone v2
it was /v2.0/tokens in keystone v3 it is /v3/auth/tokens).

Using a v2 url and config file with keystone v3:
10.0.0.8:5000/v2.0/auth/tokens -- Fails to authenticate the user,
and user can't download image.

See https://bugs.launchpad.net/glance-store/+bug/1507610 for a bug report
on this.

This means that the fix proposed by
https://review.openstack.org/#/c/238074/ parses the URL for an auth_version
and then if found will use the parsed value as the auth_version rather than
the one from the config files. Taking the url as the true source.
Therefore the image will still work as the auth_version used by glance is the
one defined in the URL meaning the correct resource id appended.

Whilst discussing it with Kairat it was proposed that we ignore the
keystone version in the URL and if it does not support the auth_version
in the configs, then the image would fail to be downloaded. This is due to a
preference to have a centralised auth_version value.

I am wondering what people would prefer to do, to support the 'old style' urls
and therefore parse the version from the url. Or to make the auth_version
common and potentially break the 'old style' database entries.



To clarify a bit the problem, this seems to be related only to the  
swift driver. Right?
   
My opinion is that, whatever we do, we must not break users of this 
code.   
   
I don't believe this information should be stored in the database,  
therefore I'd prefer going with `auth_version` and write the proper 
migrations to remove this info from the DB. 
   
I don't really know why it was put there in the first place but I'll
let folks that know this info chime in and provide some insights.   
   
Cheers, 
Flavio 


Thanks,
Niall Bunting


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

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

2015-12-04 Thread Dmitry Teselkin

Hello,

According to the CentOS7 merging plan we've merged all CentOS7 CRs and
are going to get our first builds in production CI.

Please note that failures are possible for short period of time, please
don't panic, we will keep an eye on every build to investigate and fix
ASAP. We will send another notification letter when it'll be stable
again. We are going to work on fixing issues (if any) until Sunday
(Dec, 6) since it's the next decision point when it'll be clear should
we go with CentOS7 further or revert.

I'd like to remind that merge freeze still in place, no merges allowed
until it will be explicitly notified.


On Tue, 1 Dec 2015 13:48:00 -0800
Dmitry Borodaenko  wrote:

> With bit more details, I hope this covers all the risks and decision
> points now.
> 
> First of all, current list of outstanding commits:
> https://etherpad.openstack.org/p/fuel_on_centos7
> 
> The above list has two sections: backwards compatible changes that can
> be merged one at a time even if the rest of CentOS7 support isn't
> merged, and backwards incompatible changes that break support for
> CentOS6 and must be merged (and, if needed, reverted) all at once.
> 
> Decision point 1: FFE for CentOS7
> 
> CentOS7 support cannot be fully merged on Dec 2, so it misses FF. Can
> it be allowed a Feature Freeze Exception? So far, the disruption of
> the Fuel development process implied by the proposed merge plan is
> acceptable, if anything goes wrong and we become unable to have a
> stable ISO with merged CentOS7 support on Monday, December 7, the FFE
> will be revoked.
> 
> Wed, Dec 2: Merge party
> 
> Merge party before 8.0 FF, we should do our best to merge all
> remaining feature commits before end of day (including backwards
> compatible CentOS7 support commits), without breaking the build too
> much.
> 
> At the end of the day we'll start a swarm test over the result of the
> merge party, and we expect QA to analyze and summarize the results by
> 17:00 MSK (6:00 PST) on Thu Dec 3.
> 
> Risk 1: Merge party breaks the build
> 
> If there is a large regression in swarm pass percentage, we won't be
> able to afford a merge freeze which is necessary to merge CentOS7
> support, we'll have to be merging bugfixes until swarm test pass rate
> is back around 70%.
> 
> Risk 2: More features get FFE
> 
> If some essential 8.0 features are not completely merged by end of day
> Wed Dec 2 and are granted FFE, merging the remaining commits can
> interfere with merging CentOS7 support, not just from merge conflicts
> perspective, but also invalidating swarm results and making it
> practically impossible to bisect and attribute potential regressions.
> 
> Thu, Dec 3: Start merge freeze for CentOS7
> 
> Decision point 2: Other FFEs
> 
> In the morning MSK time, we will assess Risk 2 and decide what to do
> with the other FFEs. The options are: integrate remaining commits into
> CentOS7 merge plan, block remaining commits until Monday, revoke
> CentOS7 FFE.
> 
> If the decision is to go ahead with CentOS7 merge, we announce merge
> freeze for all git repositories that go into Fuel ISO, and spend the
> rest of the day rebasing and cleaning up the rest of the CentOS7
> commits to make sure they're all in mergeable state by the end of the
> day. The outcome of this work must be a custom ISO image with all
> remaining commits, with additional requirement that it must not use
> Jenkins job parameters (only patches to fuel-main that change default
> repository paths) to specify all required package repositories. This
> will validate the proposed fuel-main patches and ensure that no
> unmerged package changes are used to produce the ISO.
> 
> Decision point 3: Swarm pass rate
> 
> After swarm results from Wed are available, we will assess the Risk 1.
> If the pass rate regression is significant, CentOS7 FFE is revoked and
> merge freeze is lifted. If regression is acceptable, we proceed with
> merging remaining CentOS7 commmits through Thu Dec 3 and Fri Dec 4.
> 
> Fri, Dec 4: Merge and test CentOS7
> 
> The team will have until 17:00 MSK to produce a non-custom ISO that
> passes BVT and can be run through swarm.
> 
> Sat, Dec 5: Assess CentOS7 swarm and bugfix
> 
> First of all, someone from CI and QA teams should commit to monitoring
> the CentOS7 swarm run and report the results as soon as possible.
> Based on the results (which once again must be available by 17:00
> MSK), we can decide on the final step of the plan.
> 
> Decision point 4: Keep or revert
> 
> If CentOS7 based swarm shows significant regression, we have to spend
> the rest of the weekend including Sunday reverting all CentOS7 commits
> that were merged during merge freeze. Once revert is completed, we
> will lift the merge freeze.
> 
> If the regression is acceptable, we lift the merge freeze straight
> away and proceed with bugfixing as usual. At this point CI team will
> need to update the Fuel ISO used for deployment tests in our CI to
> this same

Re: [openstack-dev] [nova][docs][api] Propose Virtual Nova API Doc Sprint on Dec 8 and 9

2015-12-04 Thread Alex Xu

Just reminder the event which close the time, the virtual doc sprint is
right next week. Welcome to join us!

2015-11-11 20:51 GMT+08:00 Alex Xu :

> Hi,
>
> At nova api subteam weekly meeting, we decided hold 2 days virtual doc
> sprint to help the Nova API document. The initial proposed date is Dec 8
> and 9(Let me know if the date is conflict with other thing). The sprint is
> running on local time for folks. Peoples can work on the patch and also can
> help on the review.
>
> Appreciate and welcome people join this sprint to help on API doc.
>
> Please sign up for this sprint first if you are interesting at the top of
> etherpad https://etherpad.openstack.org/p/nova-v2.1-api-doc . The tasks
> of sprint are also in the etherpad, already have some contributors work on
> those doc tasks now, so free to join us now or join the sprint.
>
> Thanks
> Alex
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

Julien Danjou wrote:
> On Fri, Dec 04 2015, Dmitry Tantsur wrote:
> 
>> Specifically, I'm talking about ironic-inspector, which is a auxiliary 
>> service
>> under the bare metal program. My first assumption is to prefix with ironic's
>> official name, so it should be something like 'baremetal-XXX' or 'baremetal
>> XXX'. Is it correct? Which separator is preferred?
> 
> FWIW we have 3 different projects under the telemetry umbrella and they
> do not share any prefix.

My take is to rename ironic-inspector to clouseau, the ironic inspector
from the Pink Panther series.

-- 
Thierry Carrez (ttx)



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] [Fuel] FFE for Ubuntu bootstrap

2015-12-04 Thread Dmitry Klenov

Hi Mike and Igor,

Thank you for the opinions.

We already talked to Matt and he is fine with Fuel Menu commit. We will
target the changes for Tuesday and will work with reviewers and Mos-Linux
team to have blocker bug resolved and commits merged.

Thanks,
Dmitry.

On Fri, Dec 4, 2015 at 2:04 PM, Igor Kalnitsky 
wrote:

> Hey Dmitry,
>
> I'm ok with FFE till Tuesday. Moreover, it makes sense to do so in
> order to reduce affection on CentOS 7 patches.
>
> - Igor
>
> On Thu, Dec 3, 2015 at 8:58 PM, Dmitry Klenov 
> wrote:
> > Hi folks,
> >
> > Let me clarify the situation with Ubuntu bootstrap feature.
> >
> > First of all, I would like to highlight that all functional commits for
> this
> > feature were merged. This means that starting from yesterday everyone
> has an
> > ability to switch to Ubuntu-based bootstrap manually and start using it.
> So
> > I do not see the risk in loosing testing cycles in the community.
> >
> > The item which brought concerns on today status meeting was the
> enablement
> > of the feature by default. To do it, 2 patches have to be merged
> together:
> > * https://review.openstack.org/#/c/250662/ - main switch.
> > * https://review.openstack.org/#/c/251908/ - compatibility commit to QA
> > suite to comply with new bootstrap config format.
> >
> > I would like to raise the question if we can have a feature freeze
> exception
> > for these 2 patches?
> >
> > There are a couple of reasons why I consider it safer to merge these
> patches
> > several days later:
> > * There is a bug caught today which will block the tests to pass if we
> > switch to Ubuntu bootstrap by default:
> > https://bugs.launchpad.net/fuel/+bug/1522406
> > * There were concerns that a lot of FF commit merges can bring
> instability
> > to QA suite. So it might be reasonable not to bring one more variable
> right
> > now and to enable ubuntu bootstrap by default when all automated tests
> are
> > stabilized.
> >
> > I would like to ask engineering and QA leads to express their ideas on
> this.
> >
> > Thanks,
> > Dmitry.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

2015-12-04 Thread Kris G. Lindgren

+1

___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Dina Belova >
Date: Friday, December 4, 2015 at 2:46 AM
To: OpenStack Development Mailing List 
>, 
openstack-operators 
>
Subject: [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

Dear performance folks,

There is a suggestion to move our meeting time from 15:00 UTC 
(Tuesdays) 
to 16:00 UTC (also 
Tuesdays) 
to make them more comfortable for US guys.

Please leave your +1 / -1 here in the email thread.

Btw +1 from me :)

Cheers,
Dina
__
OpenStack Development Mailing 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] [release] recording milestones for unmanaged projects

2015-12-04 Thread Doug Hellmann

Release liaisons,

We've had a couple of questions about handling the milestone releases
for non-release:managed projects. Today in the release team meeting,
we agreed that we would like to record the information about those
releases, after they are cut. We also want to encourage everyone
to take the same steps of removing the version entry from your
setup.cfg file, so we want to follow a similar process that we went
through with the managed teams.

1. Prepare a patch to the deliverable file in the openstack/releases
   repository recording the *existing beta tag* for your release.

   Please include a note in the commit message indicating that you
   are recording an existing milestone tag for an unmanaged project.

2. Prepare a patch to the project repository removing the version
   line from setup.cfg.

   Set the patch to depend on the release patch from step 1, and
   use the topic "remove-version-from-setup".

3. Add a comment to the milestone tag request linking to the
   review from step 2.

There's no need to rush to finish these patches, so submit them
when you have a few minutes over the next week or so.

Doug


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

[openstack-dev] [release] mitaka-1 development milestone

Hello everyone,

The first milestone of the Mitaka development cycle, "mitaka-1", is now
reached. Some OpenStack projects following the milestone-based release
schedule took the opportunity to publish a development artifact, which
contains all the new features and bugfixes that have been added since
the Liberty Feature Freeze in September:

aodh 2.0.0.0b1:
https://tarballs.openstack.org/aodh/aodh-2.0.0.0b1.tar.gz

barbican 2.0.0.0b1:
https://tarballs.openstack.org/barbican/barbican-2.0.0.0b1.tar.gz

ceilometer 6.0.0.0b1:
https://tarballs.openstack.org/ceilometer/ceilometer-6.0.0.0b1.tar.gz

cinder 8.0.0.0b1:
https://tarballs.openstack.org/cinder/cinder-8.0.0.0b1.tar.gz

designate 2.0.0.0b1:
https://tarballs.openstack.org/designate/designate-2.0.0.0b1.tar.gz
https://tarballs.openstack.org/designate-dashboard/designate-dashboard-2.0.0.0b1.tar.gz

glance 12.0.0.0b1:
https://tarballs.openstack.org/glance/glance-12.0.0.0b1.tar.gz

heat 6.0.0.0b1:
https://tarballs.openstack.org/heat/heat-6.0.0.0b1.tar.gz

horizon 9.0.0.0b1:
https://tarballs.openstack.org/horizon/horizon-9.0.0.0b1.tar.gz

keystone 9.0.0.0b1:
https://tarballs.openstack.org/keystone/keystone-9.0.0.0b1.tar.gz

manila 2.0.0.0b1:
https://tarballs.openstack.org/manila/manila-2.0.0.0b1.tar.gz

mistral 2.0.0.0b1:
https://tarballs.openstack.org/mistral/mistral-2.0.0.0b1.tar.gz

neutron 8.0.0.0b1:
https://tarballs.openstack.org/neutron/neutron-8.0.0.0b1.tar.gz
https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-8.0.0.0b1.tar.gz
https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-8.0.0.0b1.tar.gz
https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0b1.tar.gz

nova 13.0.0.0b1:
https://tarballs.openstack.org/nova/nova-13.0.0.0b1.tar.gz

sahara 4.0.0.0b1:
https://tarballs.openstack.org/sahara/sahara-4.0.0.0b1.tar.gz
https://tarballs.openstack.org/sahara-extra/sahara-extra-4.0.0.0b1.tar.gz
https://tarballs.openstack.org/sahara-image-elements/sahara-image-elements-4.0.0.0b1.tar.gz

searchlight 0.2.0.0b1:
https://tarballs.openstack.org/searchlight/searchlight-0.2.0.0b1.tar.gz

trove 5.0.0.0b1:
https://tarballs.openstack.org/trove/trove-5.0.0.0b1.tar.gz

zaqar 2.0.0.0b1:
https://tarballs.openstack.org/zaqar/zaqar-2.0.0.0b1.tar.gz

You can also find all those links (and all other mitaka intermediary
releases) at:
http://docs.openstack.org/releases/releases/mitaka.html

The next development milestone, mitaka-2, is scheduled for January
19-21, 2016.

Cheers!

-- 
Thierry Carrez (ttx)


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

[openstack-dev] [all] [infra] [java] Seeking java mirror person

2015-12-04 Thread Michael Krotscheck

Hey everyone!

A few months ago, there was a conversation in #openstack-infra, where
_someone_ asked for a maven repository mirror to speed up, and stabilize,
any java builds. Unfortunately, I can't remember for who that was, and my
grep-foo is (apparently) weak. Could the interested party please pick up
the white courtesy phone and contact me? I'm trying to gather all the
different mirror efforts (rubygems, pypi-wheel, bower, npm, java, etc)
under one coordinated umbrella.

For all the other lurkers who are curious about this topic, you can come
help review our spec and/or patches :)

Spec: https://review.openstack.org/#/c/252678/
Patches:
https://review.openstack.org/#/q/status:open+branch:master+topic:unified_mirror,n,z

Michael
__
OpenStack Development Mailing 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] [devstack] Devstack on wheezy

2015-12-04 Thread Sean M. Collins

On Mon, Nov 30, 2015 at 08:38:10AM EST, Sean Dague wrote:
> Wheezy support is best effort.
> 
> liberasurecode-dev is really about to be a hard dependency for Swift, we
> need it in our development toolchain. Someone (upstream) needs to
> provide that as a backport to wheezy if running swift on wheezy is still
> a thing people care about.

They would also need to backport a more recent version of Open vSwitch.

https://bugs.launchpad.net/devstack/+bug/1520338

I think it might be time to cut support, the list of packages that need
to be backported is only going to grow
-- 
Sean M. Collins

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

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

2015-12-04 Thread Andrey Kurilin

Hi!
15-00 or 16-00 - it does not matter to me :)

On Fri, Dec 4, 2015 at 11:46 AM, Dina Belova  wrote:

> Dear performance folks,
>
> There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> ) to
> 16:00 UTC (also Tuesdays
> ) to
> make them more comfortable for US guys.
>
> Please leave your +1 / -1 here in the email thread.
>
> Btw +1 from me :)
>
> Cheers,
> Dina
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] The ceph jobs are regressed in all branches in the gate as of 12/4

2015-12-04 Thread Sean Dague

On 12/04/2015 09:34 AM, Matt Riedemann wrote:
> Tracking with this bug:
> 
> https://bugs.launchpad.net/cinder/+bug/1520296
> 
> I suspect it was this change, or related to this change somehow:
> 
> https://review.openstack.org/#/c/251421/
> 
> Since that's the only global ceph related change I can find in the last
> 24 hours. Otherwise it could be a regression in Tempest, but there was
> nothing obvious I could find there.
> 
> The librados/librbd package versions in the test failure run were from
> September, so it doesn't appear to be a dependent package version update
> failure.

I don't think that change impacts any of the jobs that are failing. The
plugin jobs are new job names, and non voting.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [puppet] bugreporting in puppet-openstack-integration

2015-12-04 Thread Ptacek, MichalX

Hello,



I have one general question for bug-reporting in puppet-openstack-integration 
project,

Actually I am having some issues by running all-in-one.sh script,



Issue1)  default scenario003 is not executed, as variable SCENARIO is not 
exported and visible in run_test.sh

https://github.com/openstack/puppet-openstack-integration/blob/master/all-in-one.sh#L46



Issue2) when bypassed (issue1) by used correct SCENARIO  I reach another 
problem, where puppet code failed on finding tempest in /tmp/tempest

https://github.com/openstack/puppet-openstack-integration/blob/master/fixtures/scenario003.pp#L388

tempest code is available inside /tmp/openstack/tempest, cloned by following 
code

https://github.com/openstack/puppet-openstack-integration/blob/master/run_tests.sh#L39



I think these issues has to be already reported somewhere but I was not able to 
find that project in Launchpad,

How can I report problems like that or am I doing anything wrong ?



Thanks,

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


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] [Nova] [Glance] Errors Produced by Nova and Glance Interaction

2015-12-04 Thread Richard Raseley

Ivan,

Thank you for your reply.

As I noted near the bottom of my email, I came across this bug and suspected it 
was the cause, but even after upgrading to keystonemiddleware 1.5.3 I am still 
experiencing the issue. Am I stuck waiting for an updated of glanceclient as 
well or does this just impact users who pulled down the affected version of 
urllib3 during a specific time period?

Any advice on a workaround would be appreciated.

Regards,

Richard

> On Dec 4, 2015, at 12:49 AM, Ivan Derbenev  
> wrote:
> 
> Looks like this is your issue
> https://bugs.launchpad.net/glance/+bug/1476770
> 
> Regards,
> IT engineer
> Farheap, Russia
> Ivan Derbenev
> 
> From: Richard Raseley [mailto:rich...@raseley.com]
> Sent: Friday, December 4, 2015 5:50 AM
> To: openstack@lists.openstack.org
> Subject: [Openstack] [Nova] [Glance] Errors Produced by Nova and Glance 
> Interaction
> 
> I am running OpenStack Juno installed from RDO packages, all version 
> 2015.1.1-1.el7, on CentOS 7.
> 
> I am experiencing an issue whenever Nova has to interact with Glance wherein 
> it is unable to do anything other than retrieve the list of available images. 
> Here is an example:
> 
> ```
> 
> (openstack)➜  openstack  glance image-list
> +--+-+
> | ID   | Name|
> +--+-+
> | 70bcde32-dcfc-47f6-8596-9d968fae2011 | cirros-0.3.4-x86_64 |
> +--+-+
> 
> (openstack)➜  openstack  glance image-show 
> 70bcde32-dcfc-47f6-8596-9d968fae2011
> +--+--+
> | Property | Value|
> +--+--+
> | architecture | x86_64   |
> | checksum | ee1eca47dc88f4879d8a229cc70a07c6 |
> | container_format | bare |
> | created_at   | 2015-12-03T15:10:22Z |
> | description  | CirrOS 0.3.4 x86_64  |
> | disk_format  | qcow2|
> | id   | 70bcde32-dcfc-47f6-8596-9d968fae2011 |
> | min_disk | 1|
> | min_ram  | 512  |
> | name | cirros-0.3.4-x86_64  |
> | owner| bd712506c2ba41f2b1d661f97c927f8a |
> | protected| False|
> | size | 13287936 |
> | status   | active   |
> | tags | []   |
> | updated_at   | 2015-12-03T15:10:26Z |
> | virtual_size | None |
> | visibility   | private  |
> +--+--+
> 
> (openstack)➜  openstack  nova image-list
> +--+-+++
> | ID   | Name| Status | 
> Server |
> +--+-+++
> | 70bcde32-dcfc-47f6-8596-9d968fae2011 | cirros-0.3.4-x86_64 | ACTIVE |   
>  |
> +--+-+++
> 
> (openstack)➜  openstack  nova image-show 70bcde32-dcfc-47f6-8596-9d968fae2011
> ERROR (ClientException): The server has either erred or is incapable of 
> performing the requested operation. (HTTP 500) (Request-ID: 
> req-f27a5253-dc65-4689-9d89-f80ddc873e37)
> 
> ```
> 
> This is causing the inability to launch instances. Whenever this occurs, the 
> Glance API logs look clean and I see a 200 response to each request, however 
> the Nova API logs show an ‘AttributeError’ 
> (http://paste.openstack.org/show/480853/) for each request. I had originally 
> thought this was related to this bug 
> (https://bugs.launchpad.net/glance/+bug/1476770), but am still experiencing 
> it with keystonemiddleware 1.5.3, requests 2.8.1, and urllib3 1.12.
> 
> Any assistance would be greatly appreciated, as this is currently a blocking 
> issue for me.
> 
> Regards,
> 
> Richard



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

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)


On 12/04/2015 04:30 PM, Thierry Carrez wrote:

Julien Danjou wrote:

On Fri, Dec 04 2015, Dmitry Tantsur wrote:


Specifically, I'm talking about ironic-inspector, which is a auxiliary service
under the bare metal program. My first assumption is to prefix with ironic's
official name, so it should be something like 'baremetal-XXX' or 'baremetal
XXX'. Is it correct? Which separator is preferred?


FWIW we have 3 different projects under the telemetry umbrella and they
do not share any prefix.


My take is to rename ironic-inspector to clouseau, the ironic inspector
from the Pink Panther series.


You should have raised it back in the beginning of liberty, when we did 
the discoverd->inspector renaming :D






__
OpenStack Development Mailing 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-announce] [release] mitaka-1 development milestone

Hello everyone,

The first milestone of the Mitaka development cycle, "mitaka-1", is now
reached. Some OpenStack projects following the milestone-based release
schedule took the opportunity to publish a development artifact, which
contains all the new features and bugfixes that have been added since
the Liberty Feature Freeze in September:

aodh 2.0.0.0b1:
https://tarballs.openstack.org/aodh/aodh-2.0.0.0b1.tar.gz

barbican 2.0.0.0b1:
https://tarballs.openstack.org/barbican/barbican-2.0.0.0b1.tar.gz

ceilometer 6.0.0.0b1:
https://tarballs.openstack.org/ceilometer/ceilometer-6.0.0.0b1.tar.gz

cinder 8.0.0.0b1:
https://tarballs.openstack.org/cinder/cinder-8.0.0.0b1.tar.gz

designate 2.0.0.0b1:
https://tarballs.openstack.org/designate/designate-2.0.0.0b1.tar.gz
https://tarballs.openstack.org/designate-dashboard/designate-dashboard-2.0.0.0b1.tar.gz

glance 12.0.0.0b1:
https://tarballs.openstack.org/glance/glance-12.0.0.0b1.tar.gz

heat 6.0.0.0b1:
https://tarballs.openstack.org/heat/heat-6.0.0.0b1.tar.gz

horizon 9.0.0.0b1:
https://tarballs.openstack.org/horizon/horizon-9.0.0.0b1.tar.gz

keystone 9.0.0.0b1:
https://tarballs.openstack.org/keystone/keystone-9.0.0.0b1.tar.gz

manila 2.0.0.0b1:
https://tarballs.openstack.org/manila/manila-2.0.0.0b1.tar.gz

mistral 2.0.0.0b1:
https://tarballs.openstack.org/mistral/mistral-2.0.0.0b1.tar.gz

neutron 8.0.0.0b1:
https://tarballs.openstack.org/neutron/neutron-8.0.0.0b1.tar.gz
https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-8.0.0.0b1.tar.gz
https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-8.0.0.0b1.tar.gz
https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0b1.tar.gz

nova 13.0.0.0b1:
https://tarballs.openstack.org/nova/nova-13.0.0.0b1.tar.gz

sahara 4.0.0.0b1:
https://tarballs.openstack.org/sahara/sahara-4.0.0.0b1.tar.gz
https://tarballs.openstack.org/sahara-extra/sahara-extra-4.0.0.0b1.tar.gz
https://tarballs.openstack.org/sahara-image-elements/sahara-image-elements-4.0.0.0b1.tar.gz

searchlight 0.2.0.0b1:
https://tarballs.openstack.org/searchlight/searchlight-0.2.0.0b1.tar.gz

trove 5.0.0.0b1:
https://tarballs.openstack.org/trove/trove-5.0.0.0b1.tar.gz

zaqar 2.0.0.0b1:
https://tarballs.openstack.org/zaqar/zaqar-2.0.0.0b1.tar.gz

You can also find all those links (and all other mitaka intermediary
releases) at:
http://docs.openstack.org/releases/releases/mitaka.html

The next development milestone, mitaka-2, is scheduled for January
19-21, 2016.

Cheers!

-- 
Thierry Carrez (ttx)


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

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)


On 12/04/2015 03:33 PM, Julien Danjou wrote:

On Fri, Dec 04 2015, Dmitry Tantsur wrote:


Specifically, I'm talking about ironic-inspector, which is a auxiliary service
under the bare metal program. My first assumption is to prefix with ironic's
official name, so it should be something like 'baremetal-XXX' or 'baremetal
XXX'. Is it correct? Which separator is preferred?


FWIW we have 3 different projects under the telemetry umbrella and they
do not share any prefix.


Do you register all 3 in keystone? What do you use as service types?




Next step is choosing the XXX part. The process we implement in
ironic-inspector is usually referred to as "baremetal introspection" or
"baremetal inspection". The former is used for our OSC plugin, so I think our
official name should be one of
1. "baremetalintrospection" - named after the process we implement
2. "baremetalinspector" - using our code name after the official
ironic project name.


I think 1. makes more sense.


That's what I'll use if nobody objects.. I'm only undecided about the 
separator.




My 2c,

Cheers,




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

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

2015-12-04 Thread milanisko k

Please, please, please, let's use that in case we decide to have a next
major release :D

--
milan

2015-12-04 16:38 GMT+01:00 Dmitry Tantsur :

> On 12/04/2015 04:30 PM, Thierry Carrez wrote:
>
>> Julien Danjou wrote:
>>
>>> On Fri, Dec 04 2015, Dmitry Tantsur wrote:
>>>
>>> Specifically, I'm talking about ironic-inspector, which is a auxiliary
 service
 under the bare metal program. My first assumption is to prefix with
 ironic's
 official name, so it should be something like 'baremetal-XXX' or
 'baremetal
 XXX'. Is it correct? Which separator is preferred?

>>>
>>> FWIW we have 3 different projects under the telemetry umbrella and they
>>> do not share any prefix.
>>>
>>
>> My take is to rename ironic-inspector to clouseau, the ironic inspector
>> from the Pink Panther series.
>>
>
> You should have raised it back in the beginning of liberty, when we did
> the discoverd->inspector renaming :D
>
>
>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] UI experience

2015-12-04 Thread Alexandra Morozova

Hi Sergii,

Thank you very much for your feedback! We really appreciate it.

I guess, you mean Reset
 deployment and Stop
deployment buttons?

The idea here is that all potentially destructive action should be not
exposed to the users, so it will prevent accidental clicking these buttons
which will in most cases lead to broken OpenStack environment configuration.

Reset button  is hidden when there were not any
previous deploy operation with the OpenStack environment.
Stop button  is hidden when it's impossible to stop
deployment.

Maybe, you are right, that showing disabled button will be better for the
user, but let's keep in mind that it's better to hide some buttons, than to
show a number of disabled ones. That's why the current behavior looks good
for me.

P.S. and again thanks for the feedback, we really need it.

Best regards,
Morozova Alexandra
Software Developer, Mirantis, Inc.
Skype: anarchistkasan
#MorAle
+48 514501223
*Mirantis Poland Sp. z o.o.*
*Szyperska St., 14/E6*
*Poznań 61-754, Poland*
www.mirantis.com

On Fri, Dec 4, 2015 at 1:23 PM, Sergii Golovatiuk 
wrote:

> Hi,
>
> Recently I realised that some buttons disappear from UI in some
> circumstances. However, these conditions are not clear to me. I suppose we
> should change behaviour to block the button with proper caption message why
> it's blocked instead of removing it from UI completely. It will improve UX
> for advanced guys. What do you think?
>
> --
> 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 Development Mailing 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] Testing concerns around boot from UEFI spec

2015-12-04 Thread Sean Dague

On 12/03/2015 08:42 PM, Matt Riedemann wrote:
> 
> 
> On 12/3/2015 9:35 AM, Matt Riedemann wrote:
>> The boot from UEFI spec [1] is stalled a bit on testing concerns. I've
>> asked that there is integration testing (either upstream or Intel hosts
>> a 3rd party job for it), or we log a warning when it's used saying it's
>> untested and therefore considered experimental.
>>
>> I think we also want to point out UEFI boot support in the hypervisor
>> support matrix for this change, which leads me to what I think are the
>> three options:
>>
>> 1. Don't test it; this is the easy short term answer. We log the warning
>> that it's not tested and considered experimental. This is easy and
>> side-steps the quality issue, but also goes against our direction as a
>> project. [2][3]
>>
>> 2. Require Intel to provide a 3rd party CI job to test this. It sounds
>> like this might be a possibility, but I'm not entirely sure if it's
>> necessary given the last option.
>>
>> 3. Get this working in devstack and add a flag to Tempest for it, then
>> we can run it in the normal gate-tempest-dsvm-full job. I think the
>> steps (at a high level) to make this work are:
>>
>> a) install ovmf (this is in ubuntu 14.04)
>> b) setup an image with the proper uefi image metadata
>> c) configure tempest with the uefi image id (if None, it means boot from
>> uefi is not supported for the given env)
>> d) add a test to boot from uefi using the given uefi image id
>>
>> I think before we can know how feasible #3 is, someone has to test that
>> out (not it!). But given the spec freeze deadline is today, how do we
>> proceed?
>>
>> We could say in the spec #1 is the short term plan, but emphasize that
>> #3 will be investigated (but not required for the code to land in
>> mitaka).
>>
>> Unless of course people want to make 2 or 3 required for the code to
>> land.
>>
>> I'll add this to the nova meeting agenda for today.
>>
>> [1] https://review.openstack.org/#/c/235983/
>> [2] https://review.openstack.org/#/c/252543/
>> [3]
>> https://review.openstack.org/#/c/215664/9/doc/source/test_strategy.rst
>>
> 
> I already mentioned this to sdague before the nova meeting today (these
> are the things I think about while driving in the middle of nowhere),
> but option #3 won't work because boot from UEFI requires libvirt>=1.9.0,
> which we don't have in the gate (ubuntu 14.04 has liberty 1.2.2).  There
> is a newer version of libvirt in the fc21 job in the experimental queue,
> but ovmf isn't available from Fedora [1].
> 
> [1]
> https://fedoraproject.org/wiki/Using_UEFI_with_QEMU#EDK2_Licensing_Issues

Can someone explain the licensing issue here? The Fedora comments make
this sound like this is something that's not likely to end up in distros.

That seems weird enough that I'd rather push back on our Platinum Board
member to fix the licensing before we let this in. Especially as this
feature is being drive by Intel.

-Sea

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [glance] Auth_version from 'old style' URLs in the database

2015-12-04 Thread Kairat Kushaev

Hi,
there is another potential risk when using urls from database. Once
keystone v2 would be down there
is no way to request image using urls in database like 10.0.0.8:5000/v2.0.

The only possible option is to update db entries in glance but I am not
sure that it is correct solution.

I am wondering what people would prefer to do, to support the 'old style'
> urls
> and therefore parse the version from the url. Or to make the auth_version
> common and potentially break the 'old style' database entries.
>


Is there a way to prevent this? Can't we ignore auth_url from such entries
and use the auth_address
from glance_store configuration instead?

Best regards,
Kairat Kushaev

On Thu, Dec 3, 2015 at 7:24 PM, Bunting, Niall 
wrote:

> Hi,
>
> Currently glance will use an auth_url if in the database. Eg.
> 10.0.0.8:5000/v2.0
>
> However glance currently takes the auth_version from the config
> files. Therefore this can lead to a mismatch of keystone version to be used
> between the url and the config files. This is problematic due to a
> different
> resource id being required in different version of keystone (in keystone v2
> it was /v2.0/tokens in keystone v3 it is /v3/auth/tokens).
>
> Using a v2 url and config file with keystone v3:
> 10.0.0.8:5000/v2.0/auth/tokens -- Fails to authenticate the user,
> and user can't download image.
>
> See https://bugs.launchpad.net/glance-store/+bug/1507610 for a bug report
> on this.
>
> This means that the fix proposed by
> https://review.openstack.org/#/c/238074/ parses the URL for an
> auth_version
> and then if found will use the parsed value as the auth_version rather than
> the one from the config files. Taking the url as the true source.
> Therefore the image will still work as the auth_version used by glance is
> the
> one defined in the URL meaning the correct resource id appended.
>
> Whilst discussing it with Kairat it was proposed that we ignore the
> keystone version in the URL and if it does not support the auth_version
> in the configs, then the image would fail to be downloaded. This is due to
> a
> preference to have a centralised auth_version value.
>
> I am wondering what people would prefer to do, to support the 'old style'
> urls
> and therefore parse the version from the url. Or to make the auth_version
> common and potentially break the 'old style' database entries.
>
> Thanks,
> Niall Bunting
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] How to check changes waiting for review

2015-12-04 Thread Esra Celik

John, 

Thanks for the detailed answer and the page links. 
Also your reviews page seems very useful 

Regards, 
Esra Çelik 

- Orijinal Mesaj -

> Kimden: "John Garbutt" 
> Kime: "OpenStack Development Mailing List (not for usage questions)"
> 
> Gönderilenler: 4 Aralık Cuma 2015 15:00:05
> Konu: Re: [openstack-dev] [Nova] How to check changes waiting for review

> On 3 December 2015 at 13:37, Esra Celik  wrote:
> >
> > Hi,
> >
> >
> > I wonder how you follow changes waiting for review. openstack-docs offers a
> > Documentation Program Dashboard for this purpose.
> >
> > Inspired by that dashboard I prepared a link for Nova as well:
> > http://goo.gl/Msq4Lb
> >
> >
> > As I am quite new with the open source world, just to get used to with
> > github, I added a project that simply creates a review dashboard link from
> > a
> > filter file: https://github.com/esracelik/openstack-review-dashboard

> We have lots of pointers about these sorts of things in the docs here:
> https://wiki.openstack.org/wiki/Nova/Mentoring
> https://wiki.openstack.org/wiki/Nova/Process

> To specifically answer your question, we have subteams that review and
> recommend patches in here:
> https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

> Also, the blueprints page also helps track what features need reviewing:
> https://blueprints.launchpad.net/nova/mitaka

> There are also various review tools folks use to choose what patches to
> review.
> Myself, I publish stats based on infra's reviewstats:
> http://reviews.johnthetubaguy.com

> Look forward to chatting with you more on IRC.

> Thanks,
> Johnthetubaguy

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

Re: [openstack-dev] [openstack-ansible] Install Openstack-Ansible

2015-12-04 Thread Major Hayden

On Fri, 2015-12-04 at 10:01 +0530, Sharma Swati6 wrote:
> To add a new container, we have followed the steps as mentioned in
> the extra_container.yml.example. Please find the sample designate.yml
> file attached and created as per the steps.

That's a good start.  However, you'll need to sign up[1] to be an
OpenStack developer (agreeing to some contracts and things so you can
commit this into the upstream repositories.

Once you do that, you'll want to assemble a spec for the changes you
want to make.  A spec defines what you hope to accomplish and gives
everyone on the project a chance to review the steps you're planning to
take.  You can look at a spec I wrote[2] for ideas and then use the
openstack-ansible-specs template[3] to begin working on your spec.

A spec isn't busywork -- it shows the intention of what you're trying
to do and allows other people on the project to point out areas of
concern and improvement.

> To add the new roles in openstack-ansible repository, shall I create
> the directory looking at what is there for keystone or other
> components and make the configuration changes only, or can I clone it
> from somewhere also?

There is a push lately to use independent role repositories, but I'm
not sure if that's a hard requirement at the moment.  Jesse Pretorius
or Kevin Carter may be better people to talk about that in this thread.

Details on independent role repositories are in a spec[4] as well.

> Thereafter, as suggested by you, I have to test this new container
> with the existing ones.
> 
> I believe there is no such link available with such steps and 'how
> to' part for openstack-ansible. Please let me know if you/anyone else
> have already done this part to add a new component container
> similarly.

We can help you with this in IRC once you've completed the other steps
I've listed above.  Join us on Freenode in #openstack-ansible and we
will be happy to help you along the way!

[1] http://docs.openstack.org/infra/manual/developers.html
[2] 
http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/security-hardening.html
[3] 
https://github.com/openstack/openstack-ansible-specs/blob/master/specs/template.rst
[4] 
http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/independent-role-repositories.html

-- 
Major Hayden

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

[openstack-dev] [nova] Nova Mitaka-1 Update and Nova Blueprint Freeze Exceptions

2015-12-04 Thread John Garbutt

Hi,

Here are a few reminders around the Mitaka release, and info about the
blueprint freeze exception process.

Dates
-

January 21st:
Nova non-priority feature freeze
(Thats the deadline for merging the code into master)

December 8th and 9th: Virtual API document sprint
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079220.html

December 17th:
non-priority feature review bash day

More details, please see:
https://wiki.openstack.org/wiki/Nova/Mitaka_Release_Schedule
(yes, I will get that uploaded to the central location)

Reno
--

As you probably already spotted, for both nova and python-novaclient,
all release notes are now published using Reno. For more details,
please see:
http://docs.openstack.org/developer/nova/code-review.html#release-notes

Reviews
---

Lets keep focusing on these reviews:
https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

As always, good quality reviews from non-cores is vital:
https://wiki.openstack.org/wiki/Nova/Mentoring#Why_do_code_reviews_if_I_am_not_in_nova-core.3F

As previously mentioned, nova-core are actively mentoring folks to
help improve their review skills. It is this hard work (on both sides)
that lead to bauzas and alex_xu joining nova-core.
Lets keep all forms of mentoring going!

Freeze Exceptions
--

All blueprints for Mitaka should now be approved in launchpad, with
the appropriate specs merged.

So you have a spec (or specless blueprint) up for review, here is what
you need to know...
* We have over 120 blueprints already approved for Mitaka.
* Its likely only 60-70 blueprints will be completed during Mitaka.
* Please note, the non-priority feature freeze is on January 21st.
* In fairness to all, the exceptions must be... exceptional.

Preference will be given to specs and specless blueprints that are:
* part of a priority effort
* already had significant amounts of review

The deadlines for this process will be:
* Must add to etherpad by end of 9th December
* Must be approved/merged by end of 11th December
* Spec approval tracked in gerrit, two +2s to merge spec

With all that in mind, if you want to apply for an exception, please
add a link to your spec in the top of this etherpad, where it says
"Exception Requests":
https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking

Please note:
Bugs that need API changes, and so need a spec, are not affected by
the blueprint freeze. They should be fixing a bug, not adding new
functionality.

As ever, any questions, please do ask via email, IRC, etc.

Thanks,
johnthetubaguy

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

Re: [openstack-dev] [nova] Contribution to improve Nova's config option space

2015-12-04 Thread Markus Zoeller

Esra Celik  wrote on 12/04/2015 02:08:50 PM:

> From: Esra Celik 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 12/04/2015 02:09 PM
> Subject: Re: [openstack-dev] [nova] Contribution to improve Nova's 
> config option space
> 
> Thanks Markus,
> 
> I started with image_file_url opts in /nova/image/download/file.py 
> however there is note out there
> 
> # NOTE(jbresnah) because the group under which these options are added 
is
> # dyncamically determined these options need to stay out of global space
> # or they will confuse generate_sample.sh
> 
> Is it still sensible to move those opts out to nove/conf directory or 
> will I only move the filesystems opt?
> Actually is there a faster way to ask you questions about the issue?
> 
> Regards,
> Esra Çelik

Oh, great, that looks like it needs special handling... sorry.
Better start with the options at nova/virt/configdrive.py 

For realtime communication: IRC helps a lot. If you don't have a local 
client (I use XChat) you can use your browser:
http://webchat.freenode.net/?channels=openstack-nova

My nick is "markus_z". More info about IRC at:
* https://wiki.openstack.org/wiki/UsingIRC
* https://wiki.openstack.org/wiki/IRC


> Kimden: "Markus Zoeller" 
> Kime: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Gönderilenler: 4 Aralık Cuma 2015 11:37:43
> Konu: Re: [openstack-dev] [nova] Contribution to improveNova's
> configoptionspace
> 
> Esra Celik  wrote on 12/03/2015 07:58:36 PM:
> 
> > From: Esra Celik 
> > To: "OpenStack Development Mailing List (not for usage questions)" 
> > 
> > Date: 12/03/2015 07:59 PM
> > Subject: Re: [openstack-dev] [nova] Contribution to improve Nova's 
> > config option space
> > 
> > OK, got it
> > 
> > Do you have a generic IDE for remote debugging of nova, like pycharm?
> > Or how do you actually debug the code?
> > 
> > Regards
> > 
> > Esra ÇELİK
> > www.bilgem.tubitak.gov.tr
> > celik.e...@tubitak.gov.tr
> 
> Personally, I use Eclipse with the PyDev plugin but also give PyCharm
> a try. Just choose what you feel comfortable with. The Nova code has a 
> lot of unit tests which are the best documentation how the code should 
> behave. They are also easier and faster to execute than to start a whole
> system and debug it remotely. The Nova docs explain how to do it with 
> the tool *tox* [1].
> 
> [1] http://docs.openstack.org/developer/nova/unit_tests.html
> 
> Regards, Markus Zoeller (markus_z)
> 
> 
> > Kimden: "Markus Zoeller" 
> > Kime: "OpenStack Development Mailing List (not for usage questions)" 
> > 
> > Gönderilenler: 3 Aralık Perşembe 2015 20:11:08
> > Konu: Re: [openstack-dev] [nova] Contribution to improve Nova's config
> > optionspace
> > 
> > Esra Celik  wrote on 12/03/2015 06:50:49 
PM:
> > 
> > > From: Esra Celik 
> > > To: "OpenStack Development Mailing List (not for usage questions)" 
> > > 
> > > Date: 12/03/2015 06:51 PM
> > > Subject: Re: [openstack-dev] [nova] Contribution to improve Nova's 
> > > config option space
> > > 
> > > Hi Markus,
> > > 
> > > This seems to be a good one for me to start contributing to nova.
> > > And happily it will be useful for me as an openstack operator too.
> > > 
> > > I couldn't find you at IRC, maybe a little late.. 
> > > Where do you think should I start? I can see a list for config 
options
> > > at etherpad.
> > > 
> > > Thanks in advance
> > > 
> > > Esra ÇELİK
> > > www.bilgem.tubitak.gov.tr
> > > celik.e...@tubitak.gov.tr
> > 
> > Hi Esra,
> > 
> > there are some "good for starters" comments in the mentioned etherpad.
> > Just pick one of those. Maybe the 'filesystems' option. Thanks for 
your
> > help!
> > 
> > Regards, Markus Zoeller 
> > 
> > 
> > > Kimden: "Markus Zoeller" 
> > > Kime: "OpenStack Development Mailing List (not for usage questions)" 

> > > 
> > > Gönderilenler: 3 Aralık Perşembe 2015 18:10:48
> > > Konu: [openstack-dev] [nova] Contribution to improve Nova's config 
> > > optionspace
> > > 
> > > Who
> > > ===
> > > If you are a new contributor and are still searching for a way to
> > > contribute to Nova, this mail is for you. If you are not a newbie
> > > but have a bit bandwidth available, you're welcome too :)
> > > 
> > > Why
> > > ===
> > > Why you should bother?
> > > * It's an easy way to start contributing
> > > * I can offer you to help with:
> > > * pushing patches, 
> > > * debugging the gate,
> > > * dealing with reviews
> > > * and learning the general workflow
> > > * you will learn

Re: [openstack-dev] [nova] Contribution to improve Nova's config option space

2015-12-04 Thread Esra Celik

Thanks Markus, 

I started with image_file_url opts in /nova/image/download/file.py however 
there is note out there 

# NOTE(jbresnah) because the group under which these options are added is 
# dyncamically determined these options need to stay out of global space 
# or they will confuse generate_sample.sh 

Is it still sensible to move those opts out to nove/conf directory o r will I 
only move the filesystems opt? 
Actually is there a faster way to ask you questions about the issue? 

Regards, 
Esra Çelik 

- Orijinal Mesaj -

> Kimden: "Markus Zoeller" 
> Kime: "OpenStack Development Mailing List (not for usage questions)"
> 
> Gönderilenler: 4 Aralık Cuma 2015 11:37:43
> Konu: Re: [openstack-dev] [nova] Contribution to improve Nova's config option
> space

> Esra Celik  wrote on 12/03/2015 07:58:36 PM:

> > From: Esra Celik 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: 12/03/2015 07:59 PM
> > Subject: Re: [openstack-dev] [nova] Contribution to improve Nova's
> > config option space
> >
> > OK, got it
> >
> > Do you have a generic IDE for remote debugging of nova, like pycharm?
> > Or how do you actually debug the code?
> >
> > Regards
> >
> > Esra ÇELİK
> > www.bilgem.tubitak.gov.tr
> > celik.e...@tubitak.gov.tr

> Personally, I use Eclipse with the PyDev plugin but also give PyCharm
> a try. Just choose what you feel comfortable with. The Nova code has a
> lot of unit tests which are the best documentation how the code should
> behave. They are also easier and faster to execute than to start a whole
> system and debug it remotely. The Nova docs explain how to do it with
> the tool *tox* [1].

> [1] http://docs.openstack.org/developer/nova/unit_tests.html

> Regards, Markus Zoeller (markus_z)

> > Kimden: "Markus Zoeller" 
> > Kime: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Gönderilenler: 3 Aralık Perşembe 2015 20:11:08
> > Konu: Re: [openstack-dev] [nova] Contribution to improve Nova's config
> > option space
> >
> > Esra Celik  wrote on 12/03/2015 06:50:49 PM:
> >
> > > From: Esra Celik 
> > > To: "OpenStack Development Mailing List (not for usage questions)"
> > > 
> > > Date: 12/03/2015 06:51 PM
> > > Subject: Re: [openstack-dev] [nova] Contribution to improve Nova's
> > > config option space
> > >
> > > Hi Markus,
> > >
> > > This seems to be a good one for me to start contributing to nova.
> > > And happily it will be useful for me as an openstack operator too.
> > >
> > > I couldn't find you at IRC, maybe a little late..
> > > Where do you think should I start? I can see a list for config options
> > > at etherpad.
> > >
> > > Thanks in advance
> > >
> > > Esra ÇELİK
> > > www.bilgem.tubitak.gov.tr
> > > celik.e...@tubitak.gov.tr
> >
> > Hi Esra,
> >
> > there are some "good for starters" comments in the mentioned etherpad.
> > Just pick one of those. Maybe the 'filesystems' option. Thanks for your
> > help!
> >
> > Regards, Markus Zoeller
> >
> >
> > > Kimden: "Markus Zoeller" 
> > > Kime: "OpenStack Development Mailing List (not for usage questions)"
> > > 
> > > Gönderilenler: 3 Aralık Perşembe 2015 18:10:48
> > > Konu: [openstack-dev] [nova] Contribution to improve Nova's config
> > > option space
> > >
> > > Who
> > > ===
> > > If you are a new contributor and are still searching for a way to
> > > contribute to Nova, this mail is for you. If you are not a newbie
> > > but have a bit bandwidth available, you're welcome too :)
> > >
> > > Why
> > > ===
> > > Why you should bother?
> > > * It's an easy way to start contributing
> > > * I can offer you to help with:
> > > * pushing patches,
> > > * debugging the gate,
> > > * dealing with reviews
> > > * and learning the general workflow
> > > * you will learn about different functional areas and can give back
> > > to the community
> > >
> > > What
> > > 
> > > There is effort ongoing to improve the way Nova offers its
> configuration
> > > options to the operators [1]. In short, you have to read and
> understand
> > > code and describe the impact of config options as a black box so that
> > the
> > > operators don't have to read code to understand what they are
> > configuring.
> > > At the end it will look like these two patches:
> > > * https://review.openstack.org/#/c/244177/
> > > * https://review.openstack.org/#/c/246465/
> > >
> > > How
> > > ===
> > > The organization is done with an etherpad [2] which contains:
> > > * what needs to be done
> > > * how it has to be done
> > >
> > > Just ping me (markus_z) in the #openstack-nova channel (I'm in the
> > > UTC+1 timezone) or grab something out of the etherpad [2]

[openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)


Hi everyone!

I'd like to get guidance on how to pick an official name (e.g. appearing 
in keystone catalog or used in API versioning headers) for a subproject 
of an official project.


Specifically, I'm talking about ironic-inspector, which is a auxiliary 
service under the bare metal program. My first assumption is to prefix 
with ironic's official name, so it should be something like 
'baremetal-XXX' or 'baremetal XXX'. Is it correct? Which separator is 
preferred?


Next step is choosing the XXX part. The process we implement in 
ironic-inspector is usually referred to as "baremetal introspection" or 
"baremetal inspection". The former is used for our OSC plugin, so I 
think our official name should be one of
1. "baremetalintrospection" - named after the process we 
implement
2. "baremetalinspector" - using our code name after the 
official ironic project name.


WDYT? Any suggestions are welcome.

Dmitry

P.S.
This topic was raised by https://review.openstack.org/#/c/253493/ but 
also appeared in the microversioning discussion.


__
OpenStack Development Mailing 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] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

2015-12-04 Thread Ryan Moats

Apologies to those who get this twice - I'm fighting with mail
clients/servers this morning (and I'm pretty sure I'm losing)

As a US person, I'm going to vote -1 on moving to 1600 UTC on Tuesdays - I
already have too many other meetings stacked up in this slot...

Ryan Moats (regXboi)

Dina Belova  wrote on 12/04/2015 03:46:06 AM:

> From: Dina Belova 
> To: OpenStack Development Mailing List  d...@lists.openstack.org>, openstack-operators  operat...@lists.openstack.org>
> Date: 12/04/2015 03:46 AM
> Subject: [Performance][Proposal] Moving IRC meeting from 15:00 UTC
> to 16:00 UTC
>
> Dear performance folks,
>
> There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> ) to 16:00 UTC (also Tuesdays) to make them more comfortable for US guys.
>
> Please leave your +1 / -1 here in the email thread.
>
> Btw +1 from me :)
>
> Cheers,
> Dina
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

2015-12-04 Thread Julien Danjou

On Fri, Dec 04 2015, Dmitry Tantsur wrote:

> Specifically, I'm talking about ironic-inspector, which is a auxiliary service
> under the bare metal program. My first assumption is to prefix with ironic's
> official name, so it should be something like 'baremetal-XXX' or 'baremetal
> XXX'. Is it correct? Which separator is preferred?

FWIW we have 3 different projects under the telemetry umbrella and they
do not share any prefix.

> Next step is choosing the XXX part. The process we implement in
> ironic-inspector is usually referred to as "baremetal introspection" or
> "baremetal inspection". The former is used for our OSC plugin, so I think our
> official name should be one of
> 1. "baremetalintrospection" - named after the process we implement
> 2. "baremetalinspector" - using our code name after the official
> ironic project name.

I think 1. makes more sense.

My 2c,

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


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

Re: [openstack-dev] [Nova] How to check changes waiting for review

2015-12-04 Thread John Garbutt

On 3 December 2015 at 13:37, Esra Celik  wrote:
>
> Hi,
>
>
> I wonder how you follow changes waiting for review. openstack-docs offers a
> Documentation Program Dashboard for this purpose.
>
> Inspired by that dashboard I prepared a link for Nova as well:
> http://goo.gl/Msq4Lb
>
>
> As I am quite new with the open source world, just to get used to with
> github, I added a project that simply creates a review dashboard link from a
> filter file: https://github.com/esracelik/openstack-review-dashboard

We have lots of pointers about these sorts of things in the docs here:
https://wiki.openstack.org/wiki/Nova/Mentoring
https://wiki.openstack.org/wiki/Nova/Process

To specifically answer your question, we have subteams that review and
recommend patches in here:
https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

Also, the blueprints page also helps track what features need reviewing:
https://blueprints.launchpad.net/nova/mitaka

There are also various review tools folks use to choose what patches to review.
Myself, I publish stats based on infra's reviewstats:
http://reviews.johnthetubaguy.com

Look forward to chatting with you more on IRC.

Thanks,
Johnthetubaguy

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

Re: [openstack-dev] [puppet] proposing Sofer Athlan Guyot part of puppet-keystone core team

2015-12-04 Thread Sofer Athlan-Guyot

Hi,

Thanks everyone for you support.

Emilien Macchi  writes:

> Hi,
>
> For some months, Puppet OpenStack group has been very lucky to have
> Sofer working with us.
> He became a huge contributor to puppet-keystone, he knows the module
> perfectly and wrote insane amount of code recently, to bring new
> features that our community requested (some stats: [1]).
> He's always here to help on IRC and present during our weekly meetings.
>
> Core contributors, please vote if you agree to add him part of
> puppet-keystone core team.
>
> Thanks,
>
> [1]
> http://stackalytics.openstack.org/?user_id=sofer-athlan-guyot=all=loc

-- 
Sofer Athlan-Guyot

__
OpenStack Development Mailing 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] Testing concerns around boot from UEFI spec

2015-12-04 Thread Daniel P. Berrange

On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
> Can someone explain the licensing issue here? The Fedora comments make
> this sound like this is something that's not likely to end up in distros.

The EDK codebase contains a FAT driver which has a license that forbids
reusing the code outside of the EDK project.

[quote]
Additional terms: In addition to the forgoing, redistribution and use
of the code is conditioned upon the FAT 32 File System Driver and all
derivative works thereof being used for and designed only to read
and/or write to a file system that is directly managed by Intel's
Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
Specifications v.2.0 and later (together the "UEFI Specifications");
only as necessary to emulate an implementation of the UEFI Specifications;
and to create firmware, applications, utilities and/or drivers.
[/quote]

So while the code is open source, it is under a non-free license,
hence Fedora will not ship it. For RHEL we're reluctantly choosing
to ship it as an exception to our normal policy, since its the only
immediate way to make UEFI support available on x86 & aarch64

So I don't think the license is a reason to refuse to allow the UEFI
feature into Nova though, nor should it prevent us using the current
EDK bios in CI for testing purposes. It is really just an issue for
distros which only want 100% free software.

Unless the license on the existing code gets resolved, some Red Hat
maintainers have a plan to replace the existing FAT driver with an
alternative impl likely under GPL. At that time, it'll be acceptable
for inclusion in Fedora.

> That seems weird enough that I'd rather push back on our Platinum Board
> member to fix the licensing before we let this in. Especially as this
> feature is being drive by Intel.

As copyright holder, Intel could choose to change the license of their
code to make it free software avoiding all the problems. None the less,
as above, I don't think this is a blocker for inclusion of the feature
in Nova, nor our testing of it.

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

__
OpenStack Development Mailing 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] Testing concerns around boot from UEFI spec

2015-12-04 Thread Sean Dague

On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
>> Can someone explain the licensing issue here? The Fedora comments make
>> this sound like this is something that's not likely to end up in distros.
> 
> The EDK codebase contains a FAT driver which has a license that forbids
> reusing the code outside of the EDK project.
> 
> [quote]
> Additional terms: In addition to the forgoing, redistribution and use
> of the code is conditioned upon the FAT 32 File System Driver and all
> derivative works thereof being used for and designed only to read
> and/or write to a file system that is directly managed by Intel's
> Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
> and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
> Specifications v.2.0 and later (together the "UEFI Specifications");
> only as necessary to emulate an implementation of the UEFI Specifications;
> and to create firmware, applications, utilities and/or drivers.
> [/quote]
> 
> So while the code is open source, it is under a non-free license,
> hence Fedora will not ship it. For RHEL we're reluctantly choosing
> to ship it as an exception to our normal policy, since its the only
> immediate way to make UEFI support available on x86 & aarch64
> 
> So I don't think the license is a reason to refuse to allow the UEFI
> feature into Nova though, nor should it prevent us using the current
> EDK bios in CI for testing purposes. It is really just an issue for
> distros which only want 100% free software.

For upstream CI that's also a bar that's set. So for 3rd party, it would
probably be fine, but upstream won't happen.

> Unless the license on the existing code gets resolved, some Red Hat
> maintainers have a plan to replace the existing FAT driver with an
> alternative impl likely under GPL. At that time, it'll be acceptable
> for inclusion in Fedora.
> 
>> That seems weird enough that I'd rather push back on our Platinum Board
>> member to fix the licensing before we let this in. Especially as this
>> feature is being drive by Intel.
> 
> As copyright holder, Intel could choose to change the license of their
> code to make it free software avoiding all the problems. None the less,
> as above, I don't think this is a blocker for inclusion of the feature
> in Nova, nor our testing of it.

That's fair. However we could also force having this conversation again,
and pay it forward to the larger open source community by getting this
ridiculous licensing fixed. We did the same thing with some other
libraries in the past.

-Sean

-- 
Sean Dague
http://dague.net

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

[Openstack] change IP of instance

2015-12-04 Thread Ivan Derbenev

Hello!
Openstack kilo+Ubuntu 14.04
Nova-network, not neutron, vlanDHCPmanager

Is there a possibility to change ip of instance, without database hacking?

Regards,
IT engineer
Farheap, Russia
Ivan Derbenev

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

Re: [openstack-dev] [fuel] UI experience

2015-12-04 Thread Alexandra Morozova

We tend to agree with you, guys, so the appropriated bug
 created.

This annoying behavior will be fixed in this iteration.

Best regards,
Morozova Alexandra
Software Developer, Mirantis, Inc.
Skype: anarchistkasan
#MorAle
+48 514501223
*Mirantis Poland Sp. z o.o.*
*Szyperska St., 14/E6*
*Poznań 61-754, Poland*
www.mirantis.com


On Fri, Dec 4, 2015 at 2:42 PM, Aleksandr Didenko 
wrote:

> Hi,
>
> that's great to know about this new button behaviour, because I was going
> to file a bug few days ago when I was not able to find "Stop" button on UI.
> But then I updated to a more recent ISO and the button "appeared" again.
> Now I know what that was, thank you. And I can't tell that my own
> experience was good. Hiding buttons is much more confusing than disabling
> them, IMHO.
>
> Regards,
> Alex
>
> On Fri, Dec 4, 2015 at 1:35 PM, Alexandra Morozova <
> astepanc...@mirantis.com> wrote:
>
>> Hi Sergii,
>>
>> Thank you very much for your feedback! We really appreciate it.
>>
>> I guess, you mean Reset
>>  deployment
>> and Stop deployment buttons?
>>
>> The idea here is that all potentially destructive action should be not
>> exposed to the users, so it will prevent accidental clicking these buttons
>> which will in most cases lead to broken OpenStack environment configuration.
>>
>> Reset button  is hidden when there were not any
>> previous deploy operation with the OpenStack environment.
>> Stop button  is hidden when it's impossible to
>> stop deployment.
>>
>> Maybe, you are right, that showing disabled button will be better for the
>> user, but let's keep in mind that it's better to hide some buttons, than to
>> show a number of disabled ones. That's why the current behavior looks good
>> for me.
>>
>> P.S. and again thanks for the feedback, we really need it.
>>
>> Best regards,
>> Morozova Alexandra
>> Software Developer, Mirantis, Inc.
>> Skype: anarchistkasan
>> #MorAle
>> +48 514501223
>> *Mirantis Poland Sp. z o.o.*
>> *Szyperska St., 14/E6*
>> *Poznań 61-754, Poland*
>> www.mirantis.com
>>
>>
>> On Fri, Dec 4, 2015 at 1:23 PM, Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> Recently I realised that some buttons disappear from UI in some
>>> circumstances. However, these conditions are not clear to me. I suppose we
>>> should change behaviour to block the button with proper caption message why
>>> it's blocked instead of removing it from UI completely. It will improve UX
>>> for advanced guys. What do you think?
>>>
>>> --
>>> 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 Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

2015-12-04 Thread Anne Gentle

On Fri, Dec 4, 2015 at 5:03 AM, Cory Benfield  wrote:

>
> > On 4 Dec 2015, at 10:06, Thomas Goirand  wrote:
> >
> > That's actually a very good idea, I didn't think it was possible. Could
> > you explain a bit more how this kind of patch would look like?
>
> Sure. Rather than explain and take the credit, I’ll point you directly at
> the code in the Alabaster[0] repository that controls this and from where I
> ‘borrowed’ the idea.
>
> Here[1] is the code in the Alabaster ‘layout.html’ file that optionally
> includes the GA tracking script. Per the README[2], you can then set
> html_theme_options = {‘analytics_id’: }, which will cause the
> GA tracking script to be included with the appropriate ID.
>
> I’m not exactly sure where the OpenStack theme lives, but assuming it’s
> the one in oslosphinx/theme/openstack, then you’d add the appropriate
> conditional template block here[3], probably with a default value in this
> file[4].
>
> If this seems like something that’s generally desired, I’m open to making
> the actual patch to oslosphinx (or wherever the actual theme is mastered)
> myself.
>

Great, thanks! This would work well for both oslosphinx and
openstackdocstheme:

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

Anne


>
> Cory
>
> [0]: https://github.com/bitprophet/alabaster
> [1]:
> https://github.com/bitprophet/alabaster/blob/49f1bfec244609ab1a47592087342725163a2e88/alabaster/layout.html#L36-L52
> [2]:
> https://github.com/bitprophet/alabaster/blob/49f1bfec244609ab1a47592087342725163a2e88/README.rst#theme-options
> [3]:
> https://github.com/openstack/oslosphinx/blob/f8d71ac5ad023a32cbbe04e109eb2793433ee558/oslosphinx/theme/openstack/layout.html#L97-L108
> [4]:
> https://github.com/openstack/oslosphinx/blob/f8d71ac5ad023a32cbbe04e109eb2793433ee558/oslosphinx/theme/openstack/theme.conf
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [fuel] UI experience

2015-12-04 Thread Aleksandr Didenko

Hi,

that's great to know about this new button behaviour, because I was going
to file a bug few days ago when I was not able to find "Stop" button on UI.
But then I updated to a more recent ISO and the button "appeared" again.
Now I know what that was, thank you. And I can't tell that my own
experience was good. Hiding buttons is much more confusing than disabling
them, IMHO.

Regards,
Alex

On Fri, Dec 4, 2015 at 1:35 PM, Alexandra Morozova  wrote:

> Hi Sergii,
>
> Thank you very much for your feedback! We really appreciate it.
>
> I guess, you mean Reset
>  deployment and Stop
> deployment buttons?
>
> The idea here is that all potentially destructive action should be not
> exposed to the users, so it will prevent accidental clicking these buttons
> which will in most cases lead to broken OpenStack environment configuration.
>
> Reset button  is hidden when there were not any
> previous deploy operation with the OpenStack environment.
> Stop button  is hidden when it's impossible to stop
> deployment.
>
> Maybe, you are right, that showing disabled button will be better for the
> user, but let's keep in mind that it's better to hide some buttons, than to
> show a number of disabled ones. That's why the current behavior looks good
> for me.
>
> P.S. and again thanks for the feedback, we really need it.
>
> Best regards,
> Morozova Alexandra
> Software Developer, Mirantis, Inc.
> Skype: anarchistkasan
> #MorAle
> +48 514501223
> *Mirantis Poland Sp. z o.o.*
> *Szyperska St., 14/E6*
> *Poznań 61-754, Poland*
> www.mirantis.com
>
>
> On Fri, Dec 4, 2015 at 1:23 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Hi,
>>
>> Recently I realised that some buttons disappear from UI in some
>> circumstances. However, these conditions are not clear to me. I suppose we
>> should change behaviour to block the button with proper caption message why
>> it's blocked instead of removing it from UI completely. It will improve UX
>> for advanced guys. What do you think?
>>
>> --
>> 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 Development Mailing 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] [python-novaclient] history of virtual-interface commands

2015-12-04 Thread Andrey Kurilin

Hi stackers!

I have found code in novaclient related to virtual-interfaces extension[1],
but there are no cli commands for it. Since rackspace docs include
reference to `virtual-interface-list` command[2], I wonder, is there a
reason for which commands related to virtual-interfaces are missed from
upstream master?
Does anyone know the history of virtual-interfaces extension and CLI
entrypoint for it?

[1] -
https://github.com/openstack/python-novaclient/blob/2.35.0/novaclient/v2/virtual_interfaces.py
[2] -
http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/nova_list_virt_interfaces_for_server.html

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

Re: [openstack-dev] [Neutron][DVR]

2015-12-04 Thread Ryan Moats


I pretty much agree with Oleg here - I'm not sure an additional tag for
defects is needed.
The idea of a DvrImpact in the commit message is interesting, but I'm not
entirely convinced - if we
do it for one sub-project, do we need to do it for all sub-projects and
then what does that turn into?

I'm not yet for or against, I'm just trying to think what the commit
messages are going to end up looking like...

Ryan Moats (regXboi)

Oleg Bondarev  wrote on 12/04/2015 02:44:58 AM:

> From: Oleg Bondarev 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 12/04/2015 02:46 AM
> Subject: Re: [openstack-dev] [Neutron][DVR]
>
> On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hpe.com> wrote:
> Hi Carl,
> Sounds reasonable suggestion.
> Thanks
> Swami
>
> -Original Message-
> From: Carl Baldwin [mailto:c...@ecbaldwin.net]
> Sent: Thursday, December 03, 2015 10:47 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Neutron][DVR]
>
> I was going to bring this up in the meeting this morning but IRC
> troubles prevented it.
>
> After chatting with Armando, I'd like to suggest a few enhancements
> to how we're tackling DVR during this cycle.  I'm hoping that these
> changes help us to get things done faster and more efficiently.  Let
> me know if you think otherwise.
>
> First, I'd like to suggest adding DvrImpact to the comment of any
> patches that are meant to improve DVR in some way.  People have
> asked me about reviewing DVR changes.  I can show them the DVR
> backlog [1] in launchpad but it would be nice to have a DVR
specificdashboard.
> With DvrImpact in the subject, we can make it even more convenient
> to find reviews.
>
> +1
>
>
> The other change I'd like to propose is to categorize our DVR
> backlog in to three categories:  broken, scale (loadimpact), and
newfeatures.
> I'd propose that we prioritize in that order.  Anyone have any
> suggestions for how to tag or otherwise categorize and tackle these?
>
> This might be useful but honestly I don't feel a strong need for
> categorizing dvr bugs at the moment because of the amount of bugs
> (currently I see 31 when filtering by l3-dvr-backlog tag).
> l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-
> backlog + loadimpact for 'scale', l3-dvr-backlog + Wishlist for new
> (small) enhancements.
> I might be missing something though.
>
> I know there is a loadimpact (or similar) tag those.  Should we come
> up with a couple more tags to divide the rest?
>
> Thoughts?
>
> Carl
>
> [1] https://goo.gl/M5SwfS
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][bugs] Weekly Status Report

2015-12-04 Thread Markus Zoeller

Below are the bug stats of the week "Mitaka R-18".
Increases/decreases compared to "Mitaka R-20" are in parantheses.
(I missed the mail for the week Mitaka R-19)


Stats
=

New bugs which are *not* assigned to any subteam

count: 12 (-18)
query: http://bit.ly/1WF68Iu

New bugs which are *not* triaged

subteam: libvirt 
count: 13 (-3)
query: http://bit.ly/1Hx3RrL
subteam: volumes 
count: 9 (-1)
query: http://bit.ly/1NU2DM0
subteam: compute
count: 6 (+1)
query: http://bit.ly/1O72RQc
subteam: vmware
count: 5 (0)
query: http://bit.ly/1YkCU4s
subteam: network : 
count: 2 (-2)
query: http://bit.ly/1LVAQdq
subteam: db : 
count: 2 (-2)
query: http://bit.ly/1LVATWG
subteam: 
count: 66 (-23)
query: http://bit.ly/1RBVZLn

High prio bugs which are *not* in progress
--
count: 42 (+4)
query: http://bit.ly/1MCKoHA

Critical bugs which are *not* in progress
-
count: 0 (0)
query: http://bit.ly/1kfntfk

Untriaged python-novaclient bugs

count: 9 (+2)
query: http://bit.ly/1kKUDDU

Readings

* https://wiki.openstack.org/wiki/BugTriage
* https://wiki.openstack.org/wiki/Nova/BugTriage
* 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078252.html

Regards, Markus Zoeller (markus_z)

Markus Zoeller/Germany/IBM@IBMDE wrote on 11/20/2015 05:36:48 PM:

> From: Markus Zoeller/Germany/IBM@IBMDE
> To: "OpenStack Development Mailing List \(not for usage questions\)" 
> 
> Date: 11/20/2015 05:38 PM
> Subject: Re: [openstack-dev] [nova][bugs] Weekly Status Report
> 
> Below are the bug stats of the week "Mitaka R-20".
> Increases/decreases compared to "Mitaka R-21" are in parantheses.
> The bug count of the novaclient is added now.
> 
> Stats
> =
> 
> New bugs which are *not* assigned to any subteam
> 
> count: 30 (+2)
> query: http://bit.ly/1WF68Iu
> 
> New bugs which are *not* triaged
> 
> subteam: libvirt 
> count: 16 (+2)
> query: http://bit.ly/1Hx3RrL
> subteam: volumes 
> count: 10 (-2)
> query: http://bit.ly/1NU2DM0
> subteam: compute
> count: 5 (0)
> query: http://bit.ly/1O72RQc
> subteam: vmware
> count: 5 (?)
> query: http://bit.ly/1YkCU4s
> subteam: network : 
> count: 4 (0)
> query: http://bit.ly/1LVAQdq
> subteam: db : 
> count: 4 (0)
> query: http://bit.ly/1LVATWG
> subteam: 
> count: 89 (+6)
> query: http://bit.ly/1RBVZLn
> 
> High prio bugs which are *not* in progress
> --
> count: 38 (-1)
> query: http://bit.ly/1MCKoHA
> 
> Critical bugs which are *not* in progress
> -
> count: 0 (0)
> query: http://bit.ly/1kfntfk
> 
> Untriaged python-novaclient bugs
> 
> count: 7 (?)
> query: http://bit.ly/1kKUDDU
> 
> 
> Readings
> 
> * https://wiki.openstack.org/wiki/BugTriage
> * https://wiki.openstack.org/wiki/Nova/BugTriage
> * 
> 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/078252.html

> 
> Markus Zoeller/Germany/IBM@IBMDE wrote on 11/13/2015 04:07:24 PM:
> 
> > From: Markus Zoeller/Germany/IBM@IBMDE
> > To: "OpenStack Development Mailing List \(not for usage questions\)" 
> > 
> > Date: 11/13/2015 04:09 PM
> > Subject: Re: [openstack-dev] [nova][bugs] Weekly Status Report
> > 
> > Below are the stats of the week "Mitaka R-21".
> > Changes to the previous week are shown in parantheses behind the 
current
> > numbers. For example, "28 (+9)" means we have 28 bugs in that category
> > with an increase of 9 bugs comparing to the previous week.
> > 
> > 
> > Stats
> > =
> > 
> > New bugs which are *not* assigned to any subteam
> > 
> > count: 28 (+9)
> > query: http://bit.ly/1WF68Iu
> > 
> > New bugs which are *not* triaged
> > 
> > subteam: libvirt 
> > count: 14 (0)
> > query: http://bit.ly/1Hx3RrL
> > subteam: volumes 
> > count: 12 (+1)
> > query: http://bit.ly/1NU2DM0
> > subteam: compute
> > count: 5 (?)
> > query: http://bit.ly/1O72RQc
> > subteam: network : 
> > count: 4 (0)
> > query: http://bit.ly/1LVAQdq
> > subteam: db : 
> > count: 4 (0)
> > query: http://bit.ly/1LVATWG
> > subteam: 
> > count: 83 (+16)
> > query: http://bit.ly/1RBVZLn
> > 
> > High prio bugs which are

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

2015-12-04 Thread Dmitry Nikishov

Folks, there is another spec update, please take a look:
https://review.openstack.org/#/c/243340

I'm also considering splitting the blueprint/spec into smaller pieces:

1. Non-root accounts on slave nodes.
2. Non-root user account (fueladmin) on master node.
3. Running fuel services as non-superuser.
4. Running mcollective as non-root (tentative, still need a POC).

Let me know what you think.

On Tue, Nov 24, 2015 at 12:22 PM, Dmitry Nikishov 
wrote:

> Folks, I have updated a spec, please review:
> https://review.openstack.org/#/c/243340
>
> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov 
> wrote:
>
>> Stanislaw,
>>
>> proposing patches could be a viable option long-term, however, by the
>> time these patches will make it upstream, Fuel will use CentOS 7 w/ systemd.
>>
>> On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Dmitry, as we work on opensource - it would be really nice to propose
>>> patches to upstream for non-Fuel services. But if it is not an option -
>>> using puppet make sense to me.
>>>
>>> On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <
>>> dnikis...@mirantis.com> wrote:
>>>
 Stanislaw,

 I want to clarify: there are 2 types of services, run on the Fuel node:
 - Those, which are a part of Fuel (astute, nailgun etc)
 - Those, which are not (e.g. atop)

 Capabilities for the former can easily be managed via post-install
 scripts, embedded in respective package spec file (since specs are a part
 of fuel-* repo). This is a very good idea.
 Capabilities for the latter will have to be taken care of via either
 a. some external utility (puppet)
 b. rebuilding respective package with updated spec

 I'd say that (a) is still more convinient.

 Another option would be to have a fine-grained control only on Fuel
 services and leave all the other at their defaults.

 On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
 sbogat...@mirantis.com> wrote:

> Dmitry, I just propose the way I think is right, because it's strange
> enough - install package from *.deb file and then set any privileges to it
> by third-party utility. Set permissions for app now mostly managed by
> post-install scripts. Moreover - if it isn't - it should, cause if you set
> capabilities by puppet there always will be a gap between installation and
> setting permissions, so you will must bound package installation process
> with setting permissions by puppet - other way you will have no way to use
> your app.
>
> Setting setuid bits on apps is not a good idea - it is why linux
> capabilities were introduced.
>
> On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <
> dnikis...@mirantis.com> wrote:
>
>> Stanislaw,
>>
>> In my opinion the whole feature shouldn't be in the separate package
>> simply because it will actually affect the code of many, if not all,
>> components of Fuel.
>>
>> The only services whose capabilities will have to be managed by
>> puppet are those, which are installed from upstream packages (e.g. atop) 
>> --
>> not built from fuel-* repos.
>>
>> Supervisord doesn't seem to use Linux capabilities, id does setuid
>> instead:
>> https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326
>>
>> On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Dmitry, I mean whole feature.
>>> Btw, why do you want to grant capabilities via puppet? It should be
>>> done by post-install package section, I believe.
>>>
>>> Also I doesn't know if supervisord can bound process capabilities
>>> like systemd can - we could use this opportunity too.
>>>
>>> On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <
>>> dnikis...@mirantis.com> wrote:
>>>
 My main concern with using linux capabilities/acls on files is
 actually puppet support or, actually, the lack of it. ACLs are possible
 AFAIK, but we'd need to write a custom type/provider for capabilities. 
 I
 suggest to wait with capabilities support till systemd support.

 On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov <
 dnikis...@mirantis.com> wrote:

> Stanislaw, do you mean the whole feature, or just a user? Since
> feature would require actually changing puppet code.
>
> On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Dmitry, I believe it should be done via package spec as a part of
>> installation.
>>
>> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <
>> dnikis...@mirantis.com> wrote:
>>
>>> Hello folks,
>>>
>>> I have updated the

Re: [openstack-dev] [nova] [python-novaclient] microversions support

2015-12-04 Thread Kevin L. Mitchell

On Fri, 2015-12-04 at 18:58 +0200, Andrey Kurilin wrote:
> This week I added 5 patches to enable 2.7-2.11 microversions in
> novaclient[1][2][3][4][5]. I'm not bragging. Just want to ask everyone
> who are working on new microversions: Please, do not forget to add
> support of your microversion to official Nova client.

Perhaps this is something we should add to the review guidelines—no API
change can be merged to nova unless there is a pending change to
novaclient to add support?  We already more or less enforce the criteria
that no addition to novaclient can be added unless the corresponding
nova change has been merged…
-- 
Kevin L. Mitchell 
Rackspace


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

Re: [openstack-dev] [puppet] bugreporting in puppet-openstack-integration

2015-12-04 Thread Emilien Macchi

Hey Michal,

Thanks for the bug-report! Let's see inline:

On 12/04/2015 10:26 AM, Ptacek, MichalX wrote:
> Hello,
> 
>  
> 
> I have one general question for bug-reporting in
> puppet-openstack-integration project,
> 
> Actually I am having some issues by running all-in-one.sh script,
> 
>  
> 
> Issue1)  default scenario003 is not executed, as variable SCENARIO is
> not exported and visible in run_test.sh
> 
> https://github.com/openstack/puppet-openstack-integration/blob/master/all-in-one.sh#L46
> 

Here is the fix: https://review.openstack.org/253620
Please review.

> 
> Issue2) when bypassed (issue1) by used correct SCENARIO  I reach another
> problem, where puppet code failed on finding tempest in /tmp/tempest
> 
> https://github.com/openstack/puppet-openstack-integration/blob/master/fixtures/scenario003.pp#L388
> 
> tempest code is available inside /tmp/openstack/tempest, cloned by
> following code
> 
> https://github.com/openstack/puppet-openstack-integration/blob/master/run_tests.sh#L39

Here is the fix: https://review.openstack.org/253626
Please review too.

> 
> I think these issues has to be already reported somewhere but I was not
> able to find that project in Launchpad,

You're right, it's time to have a bug tracker for this repo!
Here we go:
https://launchpad.net/puppet-openstack-integration


Thanks a lot for your feedback, very valuable!
-- 
Emilien Macchi



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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

2015-12-04 18:26 GMT+01:00 Doug Hellmann :

> Excerpts from Dmitry Tantsur's message of 2015-12-04 17:38:43 +0100:
> > Hi!
> >
> > As you all probably know, we've switched to reno for managing release
> > notes. What it also means is that the release team has stopped managing
> > milestones for us. We have to manually open/close milestones in
> > launchpad, if we feel like. I'm a bit tired of doing it for inspector,
> > so I'd prefer we stop it. If we need to track release-critical patches,
> > we usually do it in etherpad anyway. We also have importance fields for
> > bugs, which can be applied to both important bugs and important features.
> >
> > During a quick discussion on IRC Sam mentioned that neutron also dropped
> > using blueprints for tracking features. They only use bugs with RFE tag
> > and specs. It makes a lot of sense to me to do the same, if we stop
> > tracking milestones.
> >
> > For both ironic and ironic-inspector I'd like to get your opinion on the
> > following suggestions:
> > 1. Stop tracking milestones in launchpad
> > 2. Drop existing milestones to avoid confusion
>
> Please don't delete anything older than Mitaka.
>

Do you have any hints how to not confuse users in this case?


>
> Doug
>
> > 3. Stop using blueprints and move all active blueprints to bugs with RFE
> > tags; request a bug URL instead of a blueprint URL in specs.
> >
> > So in the end we'll end up with bugs for tracking user requests, specs
> > for complex features and reno for tracking for went into a particular
> > release.
> >
> > Important note: if you vote for keeping things for ironic-inspector, I
> > may ask you to volunteer in helping with them ;)
> >
> > Dmitry.
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
--
-- Dmitry Tantsur
--
__
OpenStack Development Mailing 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] Documentation containing external resource links & privacy breaches

2015-12-04 Thread Anne Gentle

On Fri, Dec 4, 2015 at 10:46 AM, Cory Benfield  wrote:

>
> On 4 Dec 2015, at 13:20, Anne Gentle 
> wrote:
>
> Great, thanks! This would work well for both oslosphinx and
> openstackdocstheme:
>
> http://git.openstack.org/cgit/openstack/openstackdocstheme/
>
> Anne
>
>
> Ok, so to begin with I’ve filed a change for openstackdocstheme here:
> https://review.openstack.org/#/c/253592/
>
> This change initially leaves GA on by default, but I’d like feedback on
> that decision because I’m open to reversing that default.
>
> One further question: does anyone know if oslosphinx pulls in
> openstackdocstheme periodically, or if they’re entirely separate and I need
> to file a separate change for that repository?
>
>
Entirely separate except we help each other out when needed. :)

Anne


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


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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

2015-12-04 Thread Doug Hellmann

Excerpts from Dmitry Tantsur's message of 2015-12-04 17:38:43 +0100:
> Hi!
> 
> As you all probably know, we've switched to reno for managing release 
> notes. What it also means is that the release team has stopped managing 
> milestones for us. We have to manually open/close milestones in 
> launchpad, if we feel like. I'm a bit tired of doing it for inspector, 
> so I'd prefer we stop it. If we need to track release-critical patches, 
> we usually do it in etherpad anyway. We also have importance fields for 
> bugs, which can be applied to both important bugs and important features.
> 
> During a quick discussion on IRC Sam mentioned that neutron also dropped 
> using blueprints for tracking features. They only use bugs with RFE tag 
> and specs. It makes a lot of sense to me to do the same, if we stop 
> tracking milestones.
> 
> For both ironic and ironic-inspector I'd like to get your opinion on the 
> following suggestions:
> 1. Stop tracking milestones in launchpad
> 2. Drop existing milestones to avoid confusion

Please don't delete anything older than Mitaka.

Doug

> 3. Stop using blueprints and move all active blueprints to bugs with RFE 
> tags; request a bug URL instead of a blueprint URL in specs.
> 
> So in the end we'll end up with bugs for tracking user requests, specs 
> for complex features and reno for tracking for went into a particular 
> release.
> 
> Important note: if you vote for keeping things for ironic-inspector, I 
> may ask you to volunteer in helping with them ;)
> 
> Dmitry.
> 

__
OpenStack Development Mailing 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][neutron][upgrade] Grenade multinode partial upgrade

2015-12-04 Thread Sean M. Collins

On Mon, Nov 30, 2015 at 07:00:07AM EST, Sean Dague wrote:
> On 11/25/2015 11:42 AM, Sean M. Collins wrote:
> > The first run for the multinode grenade job completed.
> > 
> > http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/
> > 
> > I'm still getting my bearings in the grenade log output, but if I
> > understand it correctly, after upgrading Neutron, when spawning a new
> > instance we do not get successful connectivity. The odd part is we see
> > the failure twice. Once when upgrading Nova[1], then once when upgrading
> > Cinder[2]. I would have thought Grenade would have exited after just
> > failing the first time. It did do a call to worlddump.
> 
> We're calling worlddump a bunch of times in grenade during success
> operations to try to help track down why connectivity sometimes goes
> away when we don't do any actions which we think should affect it. The
> Nova operation succeeded, there is a successful ping at the end of it.
> 
> Cinder pinged, but also does ssh verification. That failed.

Ah - OK, so doing a worlddump in a grenade job is always due to
failure. Makes sense now, thank you. We'll need to track down why
instances become unreachable during that stage then.

-- 
Sean M. Collins

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

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

2015-12-04 Thread Joshua Harlow


+1 from me :)

Dina Belova wrote:

Dear performance folks,

There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
) to
16:00 UTC (also Tuesdays
) to
make them more comfortable for US guys.

Please leave your +1 / -1 here in the email thread.

Btw +1 from me :)

Cheers,
Dina


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

Re: [openstack-dev] [all][infra] All tox jobs broken, don't approve changes for now (All green again!)

2015-12-04 Thread Andreas Jaeger


On 12/04/2015 10:31 AM, Andreas Jaeger wrote:

Currently all tox jobs are broken in the OpenStack CI. The infra-team is
fixing this right now.

Please do not approve any changes until the broken patch has been
reverted and all tox jobs have been updated, we'll send an email once
this is done,


Thanks to Yolanda, we're fine now.

All jobs started between roughly 10:00 UTC this morning and 15:00 that 
use tox might have succeed - without running tox at all ;(. If in doubt, 
please check the log files.


If tox was not run, add "recheck" as review comment to rerun all tests,

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


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

[openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints


Hi!

As you all probably know, we've switched to reno for managing release 
notes. What it also means is that the release team has stopped managing 
milestones for us. We have to manually open/close milestones in 
launchpad, if we feel like. I'm a bit tired of doing it for inspector, 
so I'd prefer we stop it. If we need to track release-critical patches, 
we usually do it in etherpad anyway. We also have importance fields for 
bugs, which can be applied to both important bugs and important features.


During a quick discussion on IRC Sam mentioned that neutron also dropped 
using blueprints for tracking features. They only use bugs with RFE tag 
and specs. It makes a lot of sense to me to do the same, if we stop 
tracking milestones.


For both ironic and ironic-inspector I'd like to get your opinion on the 
following suggestions:

1. Stop tracking milestones in launchpad
2. Drop existing milestones to avoid confusion
3. Stop using blueprints and move all active blueprints to bugs with RFE 
tags; request a bug URL instead of a blueprint URL in specs.


So in the end we'll end up with bugs for tracking user requests, specs 
for complex features and reno for tracking for went into a particular 
release.


Important note: if you vote for keeping things for ironic-inspector, I 
may ask you to volunteer in helping with them ;)


Dmitry.

__
OpenStack Development Mailing 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] Rename tenant to project: discussion

2015-12-04 Thread Neil Jerram

I'm new to this discussion, but you did ask for any feedback, so ...

On 03/12/15 18:29, Smigiel, Dariusz wrote:
> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], 
> and probably forever. It will stay at least four releases, but we need to 
> decide, how to conquer problem of renaming... 
> And more important: consider if it's a problem for Neutron?
>
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but 
> unfortunately, no one finished it. Although Keystone V3 API is already 
> supported in Neutron client [2], there are still some unknowns about Neutron 
> server side. Monty Taylor is trying to address necessary (if any) changes [3].
>
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of it. 
> Some of them are just documentation and docstrings, but there are a lot of 
> places, where variables are tangled: defined in DB, used in server, accessed 
> by client. Most of places are just internal usages. The only thing where I've 
> found 'public' information about tenants is 'help' command in neutron client.
>
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller amount 
> of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to start 
> with renaming db columns. It affects a lot of places, so when finished should 
> significantly lower number of remained "tenants".
> 3. Deal with all other places.
>
> Pros:
> - variable names unification in OpenStack code base. Someone needs to start 
> this job.
> - one way to describe the same thing, instead of: tenant/account/project. 
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
>
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of 
> patchsets to be reviewed.
>
> What do you think about this? About proposed way of dealing with all changes?
> Is this change necessary?

My intuition is that we should just not do this change.  The whole world
says 'tenant' for the 'tenant' concept, particularly in the context of
networking.  Changing to a different term is just silly.

But I haven't looked into the history.  Perhaps there's some reason we
need to anyway.

Neil


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

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

2015-12-04 Thread Cory Benfield

> On 4 Dec 2015, at 13:20, Anne Gentle  wrote:
> 
> Great, thanks! This would work well for both oslosphinx and 
> openstackdocstheme:
> 
> http://git.openstack.org/cgit/openstack/openstackdocstheme/ 
> 
> 
> Anne

Ok, so to begin with I’ve filed a change for openstackdocstheme here: 
https://review.openstack.org/#/c/253592/ 

This change initially leaves GA on by default, but I’d like feedback on that 
decision because I’m open to reversing that default.

One further question: does anyone know if oslosphinx pulls in 
openstackdocstheme periodically, or if they’re entirely separate and I need to 
file a separate change for that repository?

Cory

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

[openstack-dev] [nova] [python-novaclient] microversions support

2015-12-04 Thread Andrey Kurilin

Hi stackers!
This week I added 5 patches to enable 2.7-2.11 microversions in
novaclient[1][2][3][4][5]. I'm not bragging. Just want to ask everyone who
are working on new microversions: Please, do not forget to add support of
your microversion to official Nova client.

[1] - https://review.openstack.org/#/c/251483
[2] - https://review.openstack.org/#/c/251484
[3] - https://review.openstack.org/#/c/251485
[4] - https://review.openstack.org/#/c/251486
[5] - https://review.openstack.org/#/c/253095

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

Re: [Openstack-operators] Migrate ephemeral nodes

2015-12-04 Thread Cynthia Lopes

Hi,

Creating a new volume and doing 'dd' of the content works but you would
have to delete the instances and re launch them from the new volumes:

dd if=original_disk of=/dev/vg/new_lvm bs=1M

Kind regards,
Cynthia

2015-12-04 12:24 GMT+01:00 Davíð Örn Jóhannsson :

> Is it possible to migrate ephemeral volumes from their default location to
> an ephemeral LVM volume?
>
>
> The reason for this is that we just added additional storage to the
> servers and created a volume group that we want to use as a backend for
> ephemeral storage on the compute hosts and are searching for ways to move
> instances to that without having to delete and re-create instances
> currently using /var/lib/nova/instances as backend for epithermal storage.
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec

2015-12-04 Thread Fox, Kevin M

I think efi can boot off of fat16 as well. for vm's, we may not need fat32 
support at all. Could we just remove the offending fat32 code?

Thanks,
Kevin

From: Sean Dague [s...@dague.net]
Sent: Friday, December 04, 2015 5:46 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec

On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
>> Can someone explain the licensing issue here? The Fedora comments make
>> this sound like this is something that's not likely to end up in distros.
>
> The EDK codebase contains a FAT driver which has a license that forbids
> reusing the code outside of the EDK project.
>
> [quote]
> Additional terms: In addition to the forgoing, redistribution and use
> of the code is conditioned upon the FAT 32 File System Driver and all
> derivative works thereof being used for and designed only to read
> and/or write to a file system that is directly managed by Intel's
> Extensible Firmware Initiative (EFI) Specification v. 1.0 and later
> and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI
> Specifications v.2.0 and later (together the "UEFI Specifications");
> only as necessary to emulate an implementation of the UEFI Specifications;
> and to create firmware, applications, utilities and/or drivers.
> [/quote]
>
> So while the code is open source, it is under a non-free license,
> hence Fedora will not ship it. For RHEL we're reluctantly choosing
> to ship it as an exception to our normal policy, since its the only
> immediate way to make UEFI support available on x86 & aarch64
>
> So I don't think the license is a reason to refuse to allow the UEFI
> feature into Nova though, nor should it prevent us using the current
> EDK bios in CI for testing purposes. It is really just an issue for
> distros which only want 100% free software.

For upstream CI that's also a bar that's set. So for 3rd party, it would
probably be fine, but upstream won't happen.

> Unless the license on the existing code gets resolved, some Red Hat
> maintainers have a plan to replace the existing FAT driver with an
> alternative impl likely under GPL. At that time, it'll be acceptable
> for inclusion in Fedora.
>
>> That seems weird enough that I'd rather push back on our Platinum Board
>> member to fix the licensing before we let this in. Especially as this
>> feature is being drive by Intel.
>
> As copyright holder, Intel could choose to change the license of their
> code to make it free software avoiding all the problems. None the less,
> as above, I don't think this is a blocker for inclusion of the feature
> in Nova, nor our testing of it.

That's fair. However we could also force having this conversation again,
and pay it forward to the larger open source community by getting this
ridiculous licensing fixed. We did the same thing with some other
libraries in the past.

-Sean

--
Sean Dague
http://dague.net

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

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

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

On 4 December 2015 at 08:46, Neil Jerram  wrote:

> I'm new to this discussion, but you did ask for any feedback, so ...
>
> On 03/12/15 18:29, Smigiel, Dariusz wrote:
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> [6], and probably forever. It will stay at least four releases, but we need
> to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of 'tenant'
> to 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013 [4][5]
> but unfortunately, no one finished it. Although Keystone V3 API is already
> supported in Neutron client [2], there are still some unknowns about
> Neutron server side. Monty Taylor is trying to address necessary (if any)
> changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has 3021
> of it. Some of them are just documentation and docstrings, but there are a
> lot of places, where variables are tangled: defined in DB, used in server,
> accessed by client. Most of places are just internal usages. The only thing
> where I've found 'public' information about tenants is 'help' command in
> neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> amount of code to look through, update all places and be successful :)
> > 2. Bigger challenge will be to change server side code. I'd suggest to
> start with renaming db columns. It affects a lot of places, so when
> finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> start this job.
> > - one way to describe the same thing, instead of:
> tenant/account/project. Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot of
> patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all
> changes?
> > Is this change necessary?
>
> My intuition is that we should just not do this change.  The whole world
> says 'tenant' for the 'tenant' concept, particularly in the context of
> networking.  Changing to a different term is just silly.
>
>
If you don't know the whole story why are you making these remarks?


> But I haven't looked into the history.  Perhaps there's some reason we
> need to anyway.


> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Rename tenant to project: discussion

2015-12-04 Thread Neil Jerram

Really?  I don't want to escalate, but I  think that I'm entitled:


- to have an opinion on this, regardless of how much of the history I've read


- to express that opinion in response to an explicit request for "any 
feedback", particularly when no one else had responded to that call for nearly 
24 hours.


FWIW, it's also fine with me that there is apparently a strong consensus _for_ 
this change, and I'm happy to reflect and ponder that my intuition might be 
wrong.  I'd rather have stuck my neck out and contributed to a discussion, than 
be asked later "why did no one say anything?"


Neil


From: Armando M. 
Sent: 04 December 2015 21:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Rename tenant to project: discussion



On 4 December 2015 at 08:46, Neil Jerram 
> wrote:
I'm new to this discussion, but you did ask for any feedback, so ...

On 03/12/15 18:29, Smigiel, Dariusz wrote:
> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], 
> and probably forever. It will stay at least four releases, but we need to 
> decide, how to conquer problem of renaming...
> And more important: consider if it's a problem for Neutron?
>
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but 
> unfortunately, no one finished it. Although Keystone V3 API is already 
> supported in Neutron client [2], there are still some unknowns about Neutron 
> server side. Monty Taylor is trying to address necessary (if any) changes [3].
>
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of it. 
> Some of them are just documentation and docstrings, but there are a lot of 
> places, where variables are tangled: defined in DB, used in server, accessed 
> by client. Most of places are just internal usages. The only thing where I've 
> found 'public' information about tenants is 'help' command in neutron client.
>
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller amount 
> of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to start 
> with renaming db columns. It affects a lot of places, so when finished should 
> significantly lower number of remained "tenants".
> 3. Deal with all other places.
>
> Pros:
> - variable names unification in OpenStack code base. Someone needs to start 
> this job.
> - one way to describe the same thing, instead of: tenant/account/project. 
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
>
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of 
> patchsets to be reviewed.
>
> What do you think about this? About proposed way of dealing with all changes?
> Is this change necessary?

My intuition is that we should just not do this change.  The whole world
says 'tenant' for the 'tenant' concept, particularly in the context of
networking.  Changing to a different term is just silly.


If you don't know the whole story why are you making these remarks?

But I haven't looked into the history.  Perhaps there's some reason we
need to anyway.

Neil


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

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

Re: [openstack-dev] [Manila] Midcycle meetup

2015-12-04 Thread Ben Swartzlander


On 11/19/2015 01:00 PM, Ben Swartzlander wrote:

If you planning to attend the midcycle in any capacity, please vote your
preferences here:

https://www.surveymonkey.com/r/BXPLDXT


The results of the survey were clear. Most people prefer the week of Jan 
12-14.


There was an offer to host in Roseville, CA by HP (thanks HP) but at the 
meeting yesterday most people still preferred the RTP site, so we will 
be planning on hosting the meeting in RTP that week, unless someone 
absolutely can't make that week.


What remains to be decided is whether we do Tuesday+Wednesday or 
Wednesday+Thursday. We've tried both, and the 2 day length has worked 
out very well. I personally lean towards Wednesday+Thursday, but please 
reply back to me or the list if you have a different preference.


We need to finalize the dates so people can make travel arrangements. 
I'll set the deadline to decide by Tuesday Dec 8 so people will have 5 
week to make travel plans.



-Ben

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



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

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

2015-12-04 Thread Kyle Mestery

On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau  wrote:

> Kevin Benton  wrote:
> > So obviously the stuff in the client can be updated since most of that is
> > user-facing. However, on the server side maybe we can start out by
> keeping all
> > of the internal code and DB tables the same. Then all we need to worry
> about
> > is the API translation code to start.
> >
> > Once our public-facing stuff is done, we can just start the transition to
> > project_id internally at our own pace and in much less invasive chunks.
>
> I agree with Kevin's suggestion.
>
>
++, and this is what Salvatore has previously suggested as well.


> > On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz <
> dariusz.smig...@intel.com
> > > wrote:
> >
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in
> Mitaka
> > [6], and probably forever. It will stay at least four releases, but
> we
> > need to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of
> 'tenant' to
> > 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013
> [4][5] but
> > unfortunately, no one finished it. Although Keystone V3 API is
> already
> > supported in Neutron client [2], there are still some unknowns about
> > Neutron server side. Monty Taylor is trying to address necessary (if
> any)
> > changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has
> 3021 of
> > it. Some of them are just documentation and docstrings, but there
> are a
> > lot of places, where variables are tangled: defined in DB, used in
> server,
> > accessed by client. Most of places are just internal usages. The only
> > thing where I've found 'public' information about tenants is 'help'
> > command in neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> > amount of code to look through, update all places and be successful
> :)
> > 2. Bigger challenge will be to change server side code. I'd suggest
> to
> > start with renaming db columns. It affects a lot of places, so when
> > finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> > start this job.
> > - one way to describe the same thing, instead of:
> tenant/account/project.
> > Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot
> of
> > patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all
> changes?
> > Is this change necessary?
> > Did I forget about something?
> >
> > I'll be grateful for any kind of feedback.
> >
> > Thanks,
> >  Dariusz Smigiel (dasm)
> >  Intel Technology Poland
> >
> > [1]
> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
> > [2]
> >
> https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> > [3] https://bugs.launchpad.net/neutron/+bug/1503428
> > [4]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> > [5]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> > [6]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm
> >
>
>
> __
> OpenStack Development Mailing 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] [Murano] How to debug a failed deployment?

2015-12-04 Thread Stan Lagun

Vahid,

The main log file that is missing is murano-engine log. It is murano-engine
who does the deployment. There are also no agent logs because agents are on
VMs and none of them were created.

>From what I see from you screenshots deployment task doesn't even reaches
murano-engine.

There can be 2 possible reasons for this:

1) murano-engine is not running
2) incorrect configuration of oslo.messaging.

Murano API sends tasks to murano-engine through RabbitMQ using
oslo.messaging library. Settings in your config file differ from those in
mine. For example in my config file rabbit_host is in [DEFAULT] section
while in yours it is in [oslo_messaging_rabbit]. Maybe it is okay and my
config is outdated. Maybe you use newer version of oslo.messaging that has
different config or it can be configured in several ways. I'm not sure.

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

On Fri, Dec 4, 2015 at 8:54 AM, Vahid S Hashemian  wrote:

> Dmytro, Kate, Stan,
>
> Thank you for your responses. I'll try to provide more information about
> my environment and the deployment in this note.
> Hopefully, this will give you some clue about what the issue is with my
> setup.
>
>1. The murano config file I am using is at
>http://paste.openstack.org/show/480855/
>2. The HOT package I am trying to deploy is attached
>3. A sample of log entries I see in murano log is at
>http://paste.openstack.org/show/480854/
>4. No heat stack is created at all. As I mentioned in my previous
>message, it's as if murano cannot talk to heat.
>5. Heat engine logs are at http://paste.openstack.org/show/480856/
>6. Heat API logs are at http://paste.openstack.org/show/480857/
>7. Some screen shots are also attached that show the status of
>deployment more than 30 minutes after start. Existing heat stacks show that
>the template by itself was deployed to heat without an issue.
>8. I couldn't find murano agent logs. Please let me know where I can
>find them and I'll provide those too.
>
>
>
> Regards,
> --Vahid
>
> __
> OpenStack Development Mailing 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] Announcing the OpenStack Health Dashboard

2015-12-04 Thread Matthew Treinish

Hi Everyone,

As some people may have seen already we've been working on creating a test
results dashboard up and running to visualize the state of the tests running in
the gate. You can get to the dashboard here:

http://status.openstack.org/openstack-health/#/

It's still early for this project (we only started on it back in Sept.), so not
everything is really polished yet and there are still a couple of issues and
limitations.

The biggest current limitation is based on the data store. We're using
subunit2sql as the backend for all the data and right now we only are collecting
results for tempest and grenade runs in the gate and periodic queues. This is
configurable, as any job that emits a subunit stream can use the same mechanism,
and it is something we will likely change in the future.

We also don't have any results for runs that fail before tempest starts running,
since we need a subunit stream to populate the DB with results. However, we have
several proposed paths to fix this, so it's just a matter of time. But for right
now if a job fails before tests start running it isn't counted on the dashboard.

The code for everything lives here:

http://git.openstack.org/cgit/openstack/openstack-health/

If you find an issue feel free to file a bug here:

https://bugs.launchpad.net/openstack-health

We're eager to see this grow to enable the dashboard to suit the needs of anyone
looking at the gate results.

We're tracking work items that need to be done here:

https://etherpad.openstack.org/p/openstack-health-tracking

Please feel free to contribute if you have an idea on how to improve the
dashboard, or want to take on one of the existing TODO items. The only way we'll
be able to grow this into something that fits everyone's needs is if more people
get involved in improving it.

Thanks,

Matthew Treinish


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] [kolla][nova] Orchiestrated upgrades in kolla

2015-12-04 Thread Michał Jastrzębski

Hey guys,

Orchiestrated upgrades is one of our highest priorities for M in kolla, so
following up after discussion on summit I'd like to suggest an approach:

Instead of creating playbook called "upgrade my openstack" we will create
"upgrade my nova" instead and approach to each service case by case (since
all of our running services are in dockers, this is possible).
We will also make use of image tags as version carriers, so ansible will
deploy new container only if version tag differs from what we ask it to
deploy. This will help with idempotency of upgrade process.

So let's start with nova. Upgrade-my-nova playbook will do something like
this:

0. We create snapshot of our mariadb-data container. This will affect every
service, but it's always good to have backup and rollback of db will be
manual action

1. Nova bootstrap will be called and it will perform db-migration. Since
current approach to nova code is add-only we shouldn't need to stop
services and old services should keep working on newer database. Also for
minor version upgrades there will be no action here unless there is
migration.
2. We upgrade all conductor at the same time. This should take mere seconds
since we'll have prebuilt containers
3. We will upgrade rest of controller services with using "series: 1" in
ansible to ensure rolling upgrades.
4. We will upgrade all of nova-compute services on it's own pace.

This workflow should be pretty robust (I think it is) and it should also
provide idempotency.

Thoughts?

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

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

2015-12-04 Thread Lucas Alvares Gomes

Hi,

> 1. "baremetalintrospection" - named after the process we
> implement

+1 for baremetal-introspection ( or inspection ? )

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

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

2015-12-04 Thread Doug Wiegley


> On Dec 4, 2015, at 12:40 PM, Kyle Mestery  wrote:
> 
> On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau  > wrote:
> Kevin Benton > wrote:
> > So obviously the stuff in the client can be updated since most of that is
> > user-facing. However, on the server side maybe we can start out by keeping 
> > all
> > of the internal code and DB tables the same. Then all we need to worry about
> > is the API translation code to start.
> >
> > Once our public-facing stuff is done, we can just start the transition to
> > project_id internally at our own pace and in much less invasive chunks.
> 
> I agree with Kevin's suggestion.
> 
> 
> ++, and this is what Salvatore has previously suggested as well.

There was general consensus around this at the last neutron meeting, too.

And one thing missing from your analysis is subprojects that import neutron. 
Many will be referencing tenant or tenant_id in methods, models, or dicts, and 
though those are “internal”, providing backwards compatibility would be a sane 
thing to consider.

Thanks,
dogu



>  
> > On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz 
> > 
> > >> 
> > wrote:
> >
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> > [6], and probably forever. It will stay at least four releases, but we
> > need to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of 'tenant' 
> > to
> > 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013 [4][5] 
> > but
> > unfortunately, no one finished it. Although Keystone V3 API is already
> > supported in Neutron client [2], there are still some unknowns about
> > Neutron server side. Monty Taylor is trying to address necessary (if 
> > any)
> > changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has 3021 
> > of
> > it. Some of them are just documentation and docstrings, but there are a
> > lot of places, where variables are tangled: defined in DB, used in 
> > server,
> > accessed by client. Most of places are just internal usages. The only
> > thing where I've found 'public' information about tenants is 'help'
> > command in neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> > amount of code to look through, update all places and be successful :)
> > 2. Bigger challenge will be to change server side code. I'd suggest to
> > start with renaming db columns. It affects a lot of places, so when
> > finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> > start this job.
> > - one way to describe the same thing, instead of: 
> > tenant/account/project.
> > Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot of
> > patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all 
> > changes?
> > Is this change necessary?
> > Did I forget about something?
> >
> > I'll be grateful for any kind of feedback.
> >
> > Thanks,
> >  Dariusz Smigiel (dasm)
> >  Intel Technology Poland
> >
> > [1] 
> > https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project 
> > 
> > [2]
> > 
> > https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> >  
> > 
> > [3] https://bugs.launchpad.net/neutron/+bug/1503428 
> > 
> > [4]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> >  
> > 
> > [5]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> >  
> > 
> > [6]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm 
> >

Re: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

2015-12-04 Thread Steven Dake (stdake)

Michal,

It looks pretty good but I want neo-style [1] upgrades.  If someone rebuilds a 
container with a migration, I want to make sure that container isn't deployed 
until nova DB has been upgraded.

Can you work this into your model?

Regards
-steve

[1] https://www.youtube.com/watch?v=guVAeFs5XwE

From: Michał Jastrzębski >
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Friday, December 4, 2015 at 1:50 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [kolla][nova] Orchiestrated upgrades in kolla

Hey guys,

Orchiestrated upgrades is one of our highest priorities for M in kolla, so 
following up after discussion on summit I'd like to suggest an approach:

Instead of creating playbook called "upgrade my openstack" we will create 
"upgrade my nova" instead and approach to each service case by case (since all 
of our running services are in dockers, this is possible).
We will also make use of image tags as version carriers, so ansible will deploy 
new container only if version tag differs from what we ask it to deploy. This 
will help with idempotency of upgrade process.

So let's start with nova. Upgrade-my-nova playbook will do something like this:

0. We create snapshot of our mariadb-data container. This will affect every 
service, but it's always good to have backup and rollback of db will be manual 
action

1. Nova bootstrap will be called and it will perform db-migration. Since 
current approach to nova code is add-only we shouldn't need to stop services 
and old services should keep working on newer database. Also for minor version 
upgrades there will be no action here unless there is migration.
2. We upgrade all conductor at the same time. This should take mere seconds 
since we'll have prebuilt containers
3. We will upgrade rest of controller services with using "series: 1" in 
ansible to ensure rolling upgrades.
4. We will upgrade all of nova-compute services on it's own pace.

This workflow should be pretty robust (I think it is) and it should also 
provide idempotency.

Thoughts?

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

Re: [Openstack-operators] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

2015-12-04 Thread Clint Byrum

Excerpts from Dina Belova's message of 2015-12-04 01:46:06 -0800:
> Dear performance folks,
> 
> There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> ) to
> 16:00 UTC (also Tuesdays
> ) to
> make them more comfortable for US guys.
> 
> Please leave your +1 / -1 here in the email thread.
> 
> Btw +1 from me :)

+1, this makes it actually possible for me to participate. :)

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

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

2015-12-04 Thread Clint Byrum

Excerpts from Dina Belova's message of 2015-12-04 01:46:06 -0800:
> Dear performance folks,
> 
> There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> ) to
> 16:00 UTC (also Tuesdays
> ) to
> make them more comfortable for US guys.
> 
> Please leave your +1 / -1 here in the email thread.
> 
> Btw +1 from me :)

+1, this makes it actually possible for me to participate. :)

__
OpenStack Development Mailing 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] Bug deputy process

2015-12-04 Thread Vasudevan, Swaminathan (PNB Roseville)

On 4 December 2015 at 15:15, Carl Baldwin  wrote:

> On Thu, Dec 3, 2015 at 9:29 AM, Kyle Mestery  wrote:
> > One concern I have is ensuring we rotate people, because it does take
> some
> > time, and if the same handful of rotate, they will burn out. So I
> actively
> > encourage more people to volunteer, you don't even have to be a Neutron
> core
> > reviewer to do this!
>
> It is about time for me to step up and do a week.  Is there a waiting
> list or schedule you can add me to?
>

No waiting list. We usually find out who wants to volunteer at the irc
meeting and I update list [1].

Thanks for volunteering.

[1] https://wiki.openstack.org/wiki/Network/Meetings#Bug_deputy


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

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

2015-12-04 Thread Julien Danjou

On Fri, Dec 04 2015, Dmitry Tantsur wrote:

> Do you register all 3 in keystone? What do you use as service types?

Yes: metering, alarming and metric.

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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

[openstack-dev] OpenStack Developer Mailing List Digest November 28 - December 4

2015-12-04 Thread Mike Perez

Perma link:
http://www.openstack.org/blog/2015/12/openstack-developer-mailing-list-digest-november-20151128/

Success Bot Says

* dims: cross-project, technical-debt-reduction effort pays dividends, no code
left in oslo-incubator repo anymore.
* dhellmann: horizn, searchlight, python-openstackclient, ironic-introspec,
manila, barbican, aodh, and sahara tagged for mitaka-1 milestone!
* odyssey4me: OpenStack-Ansible for Kilo and Liberty have been released.
* ttx: Nova mitaka-1 (13.0.0.0b1) published!
* flaper87: Glance m-1 is out
* AJaegar: The Networking Guide has been translated into Japanese, read it [1].
* stevemar: Got reno in all keystone projects.
* Tell us yours via IRC with a message “#success [insert success]”.

Cross-Project Specs Close to Merging

* Backwards compatibility for clients and libraries [2].
* Deprecate Individual CLIs in favor of OpenStack Client [3].
* Chronicles of Distributed Lock Manager [4].

Release Countdown For Week R-17, Dec 7-11
=
* A list of all projects with tags [5].
* There’s a known bug in Reno for release notes not appearing after merge [6].
* Teams should have retrospectives to consider how the cycle is going so far.
* Each project has a patch that removes the version field from setup.cfg file.
* Please review that as quickly as possible.
* Mitaka 2 Release: Jan 19-21
* Mitaka release schedule [7].
* Full thread:
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081351.html

The Lock Files Saga (and Where We Can Go From Here)
===
* Josh Harlow writes, different projects use file locks to ensure that no
application on the same machine can manipulate a given resource.
* Stale lock file bug happens [8] and there is no easy way to determine when a
lock file can be deleted manually.
* Proposed creative solutions [9][10].
* Josh proposes having offset locks. Create a single file X size to store
locks, instead of having a bunch of files representing locks.
- Clint says this just makes the directory of lock files look clean, but
still leaves each offset stale and has to cleaned anyway.
-- Idea: having a cron job which deletes lock files within a set reasonable
time.
* Ben Nemec feels this is largely cosmetic complaints about not cleaning up old
files. The amount of trouble we’ve had with interprocess locking in the past,
he has never felt that a cosmetic issue was sufficient reason to relook at
the issue.
* Clint feels what’s missing is metadata for cleaning up stale locks. That can
be done with:
- fcntl locks - You have the kernel telling you for sure if the locking
process is still alive when you want to clean up and take the lock.
- Creation locks - You need to write that information into the locks, and
remove it, and then have a way to make sure the process is alive and know
it has the lock, which isn’t simple.
* Full thread:
http://lists.openstack.org/pipermail/openstack-dev/2015-December/080938.html

Recording Milestones For Unmanaged Projects
===
* Projects with non-release:managed tag should:
- Prepare a patch to the deliverable file in openstack/releases repository
recording the existing beta tag for your release. Include in the commit
message
that you are recording an existing milestone tag.
-- Prepare a patch to the project repository removing the version line from
setup.cfg. This patch should depend on the release patch with the topic
“remove-version-from-setup”.
-- Add a comment to the milestone tag request linking to the review from
step 2.
* Full thread:
http://lists.openstack.org/pipermail/openstack-dev/2015-December/081431.html

Cross-Project Spec Liaisons
===
* Mike Perez writes about problems we have with cross-project specs today:
- Authors of specs can’t progress forward with specs because of lack of
attention. Eventually getting frustrated and giving up.
- Some projects could miss a cross-project spec being approved by the TC.
* A proposal was given on the list and discussed at the cross-project meeting
[11] to have cross-project spec liaisons from each project with the following
responsibilities:
- Watching the cross-project spec repo [12].
-- Comment on specs that involve your project. +1 to carry forward for TC
approval.
--- If you’re not able to provide technical guidance on certain specs
for your project, it’s up to you to get the right people involved.
--- Assuming you get someone else involved, it’s up to you to make sure
they keep up with communication.
* Communicate back to your project’s meeting on certain cross-project specs
when necessary. This is also good for the previous bullet point of sourcing
who would have technical knowledge for certain specs.
* Attend the

Re: [openstack-dev] [murano] Is there blueprint to add argument collection UI for action

2015-12-04 Thread Stan Lagun

Tony,

Here is the blueprint:
https://blueprints.launchpad.net/murano/+spec/action-ui

The problem is much bigger then it seems to. Action parameters are very
similar to regular application properties and thus there should be a
dedicated dynamic UI form (think ui.yaml) for each action describing its
inputs.
We discussed it many times and each time the resolution was that it is
better to do major refactoring of dynamic UI forms before introducing
additional forms. The intention was to either simplify or completely get
rid of ui.yaml because it is yet another DSL to learn. Most of the
information from ui.yaml could be obtained by examining MuranoPL class
properties. And what is missing could be added as additional metadata right
to the classes. However a lot of work requires to do it properly (starting
from new API that would be MuranoPL-aware). That's why we still have no
proper UI for the actions.

Maybe we should reconsider and to have many ui forms in single package
until we have a better solution.

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

On Fri, Dec 4, 2015 at 5:42 AM, WANG, Ming Hao (Tony T) <
tony.a.w...@alcatel-lucent.com> wrote:

> Dear Stan and Murano developers,
>
>
>
> The current murano-dashboards can add the action button for the actions
> defined in Murano class definition automatically, which is great.
>
> Is there any blueprint to add argument collection UI for the action?
>
> Currently, the murano-dashboards only uses environment_id + action_id to
> run the actions, and user has no way to provide action arguments from
> UI.
>
>
>
> Thanks in advance,
>
> Tony
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Announcing the OpenStack Health Dashboard

Cool!.

From: Paul Michali [mailto:p...@michali.net]
Sent: Friday, December 04, 2015 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Announcing the OpenStack Health Dashboard

Sweet!

On Fri, Dec 4, 2015 at 3:40 PM Matthew Treinish 
> wrote:
Hi Everyone,

As some people may have seen already we've been working on creating a test
results dashboard up and running to visualize the state of the tests running in
the gate. You can get to the dashboard here:

http://status.openstack.org/openstack-health/#/

It's still early for this project (we only started on it back in Sept.), so not
everything is really polished yet and there are still a couple of issues and
limitations.

The biggest current limitation is based on the data store. We're using
subunit2sql as the backend for all the data and right now we only are collecting
results for tempest and grenade runs in the gate and periodic queues. This is
configurable, as any job that emits a subunit stream can use the same mechanism,
and it is something we will likely change in the future.

We also don't have any results for runs that fail before tempest starts running,
since we need a subunit stream to populate the DB with results. However, we have
several proposed paths to fix this, so it's just a matter of time. But for right
now if a job fails before tests start running it isn't counted on the dashboard.

The code for everything lives here:

http://git.openstack.org/cgit/openstack/openstack-health/

If you find an issue feel free to file a bug here:

https://bugs.launchpad.net/openstack-health

We're eager to see this grow to enable the dashboard to suit the needs of anyone
looking at the gate results.

We're tracking work items that need to be done here:

https://etherpad.openstack.org/p/openstack-health-tracking

Please feel free to contribute if you have an idea on how to improve the
dashboard, or want to take on one of the existing TODO items. The only way we'll
be able to grow this into something that fits everyone's needs is if more people
get involved in improving it.

Thanks,

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

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

On 4 December 2015 at 10:02, Kevin Benton  wrote:

> So obviously the stuff in the client can be updated since most of that is
> user-facing. However, on the server side maybe we can start out by keeping
> all of the internal code and DB tables the same. Then all we need to worry
> about is the API translation code to start.
>
> Once our public-facing stuff is done, we can just start the transition to
> project_id internally at our own pace and in much less invasive chunks.
>

This plan is sensible, and kudos to Dariusz to take it on...this is no
small feat of engineering and it won't be the effort of a single...we're
all here to help. Let me state the obvious and remind that this is not a
mechanical search and replace effort. We gotta be extra careful to support
both terms in the process.

To sum it up I see the following steps:

1) Make or figure out how the server can talk to the v3 API - which is bug
1503428. If Monty is unable to tackle it soon, I am sure he'll be happy to
hand it back and Darius, perhaps, can take over

This will ensure that if for whatever reason v2 gets pulled out tomorrow
(not gonna happen, but still), we're not left high and dry. To achieve
this, I think we don't invasively need to change tenant id with project id,
but only where it's key to get/validate a token.

2) Start from the client to allow to handle both project_id and tenant_id.

The server must be enhanced to be able to convert project_id to tenant_id
on the fly. The change should be relatively limited in a few places, like
where the request come in. At this time nothing else is required to change
in the server.

3) Tackle the data model.

I wonder if we could leverage some sqlalchemy magic to support both
project_id and tenant_id in the db logic, seamlesslysomething worth
investigating (zzzeek may be of help here). The sooner we start here, the
sooner we catch and fix breakages

4) Tackle the codebase sweep.

As for projects that use neutron and use the internal APIs, I can't see a
clean way of handling the bw compat if not by sprinkling decorators that
will take the signature of all the affected methods and convert the
tenant_id, but we could definitely explore how this would look like.

> On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz <
> dariusz.smig...@intel.com> wrote:
>
>> Hey Neutrinos (thanks armax for this word :),
>> Keystone is planning to deprecate V2 API (again :). This time in Mitaka
>> [6], and probably forever. It will stay at least four releases, but we need
>> to decide, how to conquer problem of renaming...
>> And more important: consider if it's a problem for Neutron?
>>
>> I'm looking at blueprint [1] about renaming all occurrences of 'tenant'
>> to 'project', and trying to find out all the details.
>> First attempt to solve this problem was raised in November 2013 [4][5]
>> but unfortunately, no one finished it. Although Keystone V3 API is already
>> supported in Neutron client [2], there are still some unknowns about
>> Neutron server side. Monty Taylor is trying to address necessary (if any)
>> changes [3].
>>
>> Findings:
>> I've focused on two projects: python-neutronclient and neutron.
>> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of
>> it. Some of them are just documentation and docstrings, but there are a lot
>> of places, where variables are tangled: defined in DB, used in server,
>> accessed by client. Most of places are just internal usages. The only thing
>> where I've found 'public' information about tenants is 'help' command in
>> neutron client.
>>
>> Suggested plan for conquer:
>> 1. First step would be to deal with neutronclient. It's much smaller
>> amount of code to look through, update all places and be successful :)
>> 2. Bigger challenge will be to change server side code. I'd suggest to
>> start with renaming db columns. It affects a lot of places, so when
>> finished should significantly lower number of remained "tenants".
>> 3. Deal with all other places.
>>
>> Pros:
>> - variable names unification in OpenStack code base. Someone needs to
>> start this job.
>> - one way to describe the same thing, instead of: tenant/account/project.
>> Helpful, especially for newcomers.
>> - alignment with Keystone V3 API
>>
>> Cons:
>> - A. Lot. Of. Work.
>> - dealing with DB migrations
>> - about 2-4 weeks of work for every part of code. Additional, a lot of
>> patchsets to be reviewed.
>>
>> What do you think about this? About proposed way of dealing with all
>> changes?
>> Is this change necessary?
>> Did I forget about something?
>>
>> I'll be grateful for any kind of feedback.
>>
>> Thanks,
>>  Dariusz Smigiel (dasm)
>>  Intel Technology Poland
>>
>> [1]
>> https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
>> [2]
>> https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
>> [3] https://bugs.launchpad.net/neutron/+bug/1503428
>> [4]
>>

Re: [openstack-dev] [Neutron][DVR]

On 4 December 2015 at 00:44, Oleg Bondarev  wrote:

>
>
> On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hpe.com> wrote:
>
>> Hi Carl,
>> Sounds reasonable suggestion.
>> Thanks
>> Swami
>>
>> -Original Message-
>> From: Carl Baldwin [mailto:c...@ecbaldwin.net]
>> Sent: Thursday, December 03, 2015 10:47 AM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [Neutron][DVR]
>>
>> I was going to bring this up in the meeting this morning but IRC troubles
>> prevented it.
>>
>> After chatting with Armando, I'd like to suggest a few enhancements to
>> how we're tackling DVR during this cycle.  I'm hoping that these changes
>> help us to get things done faster and more efficiently.  Let me know if you
>> think otherwise.
>>
>> First, I'd like to suggest adding DvrImpact to the comment of any patches
>> that are meant to improve DVR in some way.  People have asked me about
>> reviewing DVR changes.  I can show them the DVR backlog [1] in launchpad
>> but it would be nice to have a DVR specific dashboard.
>> With DvrImpact in the subject, we can make it even more convenient to
>> find reviews.
>>
>
> +1
>
>
>>
>> The other change I'd like to propose is to categorize our DVR backlog in
>> to three categories:  broken, scale (loadimpact), and new features.
>> I'd propose that we prioritize in that order.  Anyone have any
>> suggestions for how to tag or otherwise categorize and tackle these?
>>
>
> This might be useful but honestly I don't feel a strong need for
> categorizing dvr bugs at the moment because of the amount of bugs
> (currently I see 31 when filtering by l3-dvr-backlog tag).
> l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-backlog
> + loadimpact for 'scale', l3-dvr-backlog + Wishlist for new (small)
> enhancements.
> I might be missing something though.
>

That's a good point:

* High/Critical ==> DVR doesn't do what it's supposed to do
* LoadImpact ==> DVR doesn't break but it takes forever to complete
* Wishlist ==> DVR doesn't do this, but it'd be nice if it did

My suggestion was not so much to add an extra layer of classification, but
to figure out how to prioritize review/coding efforts of bugs in these
categories in a way so that each area sees progress at a similar rate.
Easier said than done :)


>
>
>> I know there is a loadimpact (or similar) tag those.  Should we come up
>> with a couple more tags to divide the rest?
>>
>> Thoughts?
>>
>> Carl
>>
>> [1] https://goo.gl/M5SwfS
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] Cinder V1 endpoints

2015-12-04 Thread Anne Gentle

On Thu, Dec 3, 2015 at 9:33 AM, Salman Toor  wrote:

> Hi,
>
> In the following link of Kilo document the cinder V1 endpoints have v2 in
> it.
>
>
> http://docs.openstack.org/kilo/install-guide/install/yum/content/cinder-install-controller-node.html
>
> openstack endpoint create \
>   --publicurl http://*controller*:8776/v2/%\(tenant_id\)s \
>   --internalurl http://*controller*:8776/v2/%\(tenant_id\)s \
>   --adminurl http://*controller*:8776/v2/%\(tenant_id\)s \
>   --region RegionOne \
>   volume
>
> Shouldn’t it be like following (colour in RED)
>
> openstack endpoint create \
>   --publicurl http://*controller*:8776/v1/%\(tenant_id\)s \
>   --internalurl http://*controller*:8776/v1/%\(tenant_id\)s \
>   --adminurl http://*controller*:8776/v1/%\(tenant_id\)s \
>   --region RegionOne \
>   volume
>
>
> Is that a documentation error? Can someone please confirm?
>
>
>
For the install documentation, especially one in use for and tested as many
months as the Kilo one, you can be assured it is not a documentation error.

It is a specific choice by our install doc team to ensure that all requests
are redirected to a v2 endpoint. Otherwise your Dashboard will not display
the Block Storage information.

If you're ever in doubt, feel free to search through fixed documentation
bugs or read the commentary, such as:
https://bugs.launchpad.net/openstack-manuals/+bug/1508355

Thanks,
Anne


> Thanks in advance.
>
> Regards..
> Salman.
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion