date:20151016

Hi, see my answers inline.

> On 16 Oct 2015, at 12:35, WANG, Ming Hao (Tony T) 
>  wrote:
> 
> We have developed some Ansible playbooks for operation automation, and we are 
> investigating if we can change the automation engine from Ansible to Mistral 
> since Mistral has powerful workflow control.
> Could you please help to provide how to let Mistral call Ansible playbook or 
> Ansible module?

I would recommend to write a custom action (not ad-hoc actions in DSL, they are 
pretty limited). You can just write a python class and make it available in 
Mistral workflow. It is pretty easy to do and described at [1]. In Python 
you’ll have more control on how to call ansible properly. If you have any 
specific questions on that you can join our IRC channel #openstack-mistral and 
talk to us there.

> My understanding is to use ssh std_action to let Mistral access Ansible 
> server to call Ansible playbook/modules since Mistral ad-hoc action must base 
> on an existing system action.

Yes, you can use std.ssh action but I guess it won’t be too convenient because 
you’ll have to deal with shell commands directly. Yes, ad-hoc actions can help 
you do it in a more elegant manner but they are pretty limited and allow to 
create only wrappers. With Python custom actions (it can be a class hierarchy, 
for example) you can do much more. For instance, you can expose individual 
ansible actions and transform their params in a form that better fits workflow 
DSL.

Anyway, it’s just my preference. You may like this second option better.

> Another question is:
> If we install Mistral and Ansible on a same server, is it possible to 
> simplify it?

Yes, like I described above.

[1] 
http://docs.openstack.org/developer/mistral/developer/creating_custom_action.html

Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] [stable/liberty] [requirements]/[oslo] ceilometer jobs failing.

2015-10-16 Thread Davanum Srinivas

Tony,

yes, planning to do a oslo.messaing 2.6.2 on monday.

-- dims

On Fri, Oct 16, 2015 at 7:21 AM, Tony Breeds 
wrote:

> Hi All,
> We have an issue for any review that causes a new commit to
> ceilometer, it
> will fail with[1]:
>
> ValueError: git history requires a target version of
> pbr.version.SemanticVersion(5.0.1), but target version is
> pbr.version.SemanticVersion(5.0.0)
>
> Switching to post-versioning[2] can't land because of [3]  The fix for
> that is
> to ban 2.6.1 (and 2.6.0) from requirements.  That can't land because of[1],
> and we've come full circle.
>
> I can't use Depends-On as the patches in each repo need to land at the same
> time.  So I tried the "obvious squash" patch at [4], but that isn't going
> to
> work because of the sensible requirements checking.
>
> The only way it fix this I can think of is to release 2.6.2 of
> oslo.messaging
> with the fixes needed by ceilometer (which have merged).
>
> I can think of a couple of rather terrible ways to hack around this but
> lets
> not go there unless there is a good reason to not release 2.6.2
>
> Yours Tony.
>
> [1] https://bugs.launchpad.net/ceilometer/+bug/1506805
> [2] https://review.openstack.org/#/c/235207/
> [3] https://bugs.launchpad.net/oslo.messaging/+bug/1505730
> [4] https://review.openstack.org/#/c/235815/
> [5] https://review.openstack.org/#/c/235536/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing 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][stable] proactive backporting

2015-10-16 Thread Armando M.

On 16 October 2015 at 10:09, Sean M. Collins  wrote:

> On Fri, Oct 16, 2015 at 11:36:13AM EDT, Salvatore Orlando wrote:
> > It might also make sense to ask contributors to resume the habit of
> tagging
> > bugs with 'backport-potential' even if not in the RC period.
>
> I like this idea because it'll make Ihar's job easier :)
>

I am in!! I made sure the stable branch policy [1] is evangelized through
the bug report guidelines [2] so that people get more and more comfortable
tagging 'backport-potential' bugs themselves when they file reports.

[1] https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy
[2]
http://docs.openstack.org/developer/neutron/policies/bugs.html#bug-screening-best-practices


>
> --
> 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
>
__
OpenStack Development Mailing 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][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

Excerpts from Jeremy Stanley's message of 2015-10-16 15:46:33 +:
> On 2015-10-16 15:03:57 + (+), Neil Jerram wrote:
> [...]
> > Surely it must be intended to be browseable?  If it was intended as a
> > clone URL, shouldn't it be presented in plain text, instead of as a link?
> 
> That's my assumption as well. So given this, it's probably better to
> think about our cgit interface URLs as being:
> 
> http(s)://git.openstack.org/cgit//
> 
> Problem here is, _html_page_context() assumes currently that the
> origin in your repo will always be in the form of:
> 
> :
> 
> This is a bad assumption for a couple reasons:
> 
>   * Depending on how the job is constructed in our CI, the origin
> may be reset to a proxied URL which isn't formed in the expected
> fashion. In this case you can see it happen in a recent job
> log[*], demonstrating this as the underlying source of the
> unexpected URL path.

OK, I didn't realize we did this.

> 
>   * You never know what the form of a developer's local origin URL
> might be, so this is likely locally broken for a lot of people
> anyway. For example, I usually clone with a .git extension on
> the URL because I'm a pedant (there are plenty of ways this
> assumption could go wrong, this is merely one of them).

I wasn't worried about supporting the local build case for this. Do you
think we need to?

> 
> There are probably a few ways to go about tweaking oslosphinx to
> correct this. In my mind, for the sake of reusability, it would make
> most sense to do something like:
> 
> 1.  Check some documented envvar like OPENSTACK_PROJECT_NAME and
> expect it to contain something in the form of
> /. This way we can explicitly set it in our
> CI jobs to an already populated variable like ZUUL_PROJECT which
> contains this information.

That sounds like way more work than is useful for such a small
feature.

> 
> 2.  If OPENSTACK_PROJECT_NAME is not set, check an optional
> extension parameter in doc/source/conf.py so that projects can
> explicitly set their source URL (this improves downstream
> consumability of the extension).

Defining a config value and updating every project to set it also seemed
like more work than the outcome warranted. Defining the option is easy,
but that's a lot of project patches.

> 
> 3.  If there's no envvar or Sphinx config override, guess from the
> origin with a somewhat more thorough regex like
> '/([^/]+/[^/]$)(\.git|)$' to be able to omit leading path nodes
> and any .git extension. This is also not perfect, but is at
> least better than the present situation and will get these links
> working correctly on docs.openstack.org for now.
> 

__
OpenStack Development Mailing 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] [neutron] A larger batch of questions about configuring DevStack to use Neutron

2015-10-16 Thread Sean M. Collins

On Fri, Oct 16, 2015 at 02:02:57AM EDT, Mike Spreitzer wrote:
> Now I have tested the first section (taking the latest of both changes) 
> using stable/liberty, and it failed because br-ex was not created 
> automatically.  I opened https://bugs.launchpad.net/devstack/+bug/1506733
> 
> I think Kilo did not have this problem.
> 

Ok. I have assigned myself the bug. I will be sightseeing with my partner
Caroline in Tokyo next week before the summit, so it may take me a
little bit of time to get around to it, but I will try and follow up on
the bug after the summit.

-- 
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] [Cinder] New extension API for detecting cinder-backup ?

2015-10-16 Thread Ramakrishna, Deepti

Thanks Duncan.

Should I publish a BP and spec for this? And follow it up with code changes to 
the server, client, horizon and documentation?

Thanks,
Deepti

From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: Friday, October 16, 2015 1:08 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Cinder] New extension API for detecting 
cinder-backup ?


I think option 2 is the better one, and we can just call it something else 
other than capabilities. Available_services or similar
On 16 Oct 2015 11:05, "Ramakrishna, Deepti" 
> wrote:
Hi,

We need a way to let Horizon know about the presence of cinder-backup service 
so that it can enable the volume backup operations in the UI 
(https://bugs.launchpad.net/cinder/+bug/1334856).

The backup action does not have any restrictions on who can perform it as 
evidenced by the following policy in 
etc/cinder/policy.json:
"backup:create" : ""

However, the only API that can tell Horizon about the existence of this 
service, namely the "os-services" API extension (that corresponds to the 
"cinder service-list" client command) is admin-only:
"volume_extension:services:index": "rule:admin_api"

Today, Horizon 
uses a config 
setting "enable_backup", that needs to be manually set in order to enable 
backup functionality in Horizon. We need a way for Horizon to figure this out 
itself, programmatically.

I can think of two ways:

  1.  Modify the services:index action to take a details=true/false parameter 
(http://{cinder-endpoint}/v2/{tenant-id}/os-services?details=false).
 And define different policies for detail=true(admin_api) and detail=false ("" 
i.e. unrestricted).

 *   "volume_extension:services:index_with_details": "rule:admin_api"
 *   "volume_extension:services:index_without_details": "”

  1.  Raise the abstraction level by creating a Cinder API extension that 
returns the list of "service capabilities". That is, the list of functionality 
that the cinder service supports. This will return only "volume backup" for now 
but can be augmented as new capabilities are added to Cinder.

I don't know if #1 can be implemented in a backward compatible way and also 
whether there is precedence for splitting the policy of a single API call based 
on parameters.
#2 seems the traditional way to do it, but I am afraid that "service 
capabilities" terminology clashes with existing "volume capabilities" 
extension,
 which has a different purpose.

I would appreciate any input on this.

Thanks,
Deepti


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

2015-10-16 Thread Fox, Kevin M

Yeah. That sounds great. Thanks. :)

Alexander, would you be able to make it?

Thanks,
Kevin

From: Serg Melikyan [smelik...@mirantis.com]
Sent: Friday, October 16, 2015 10:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [app-catalog] [glance] [murano] Data Assets API 
for App Catalog

Hi Kevin,

>Can we get together at the summit and discuss further?
I would be happy to add this meeting to the Murano summit schedule, we
have table on contributors meetup for the whole Friday. Will it be
convenient?

This is very important for Murano, it would be great to seat together
and think what actual requirements we have and how to satisfy them.

On Fri, Oct 16, 2015 at 7:44 PM, Fox, Kevin M  wrote:
> I agree that there’s a lot more room for cross project communication here at
> very least. I was really hoping that we could get representatives from the
> glance artifact subproject, the app-catalog, and the Murano teams in a room
> at the summit and hash out some of this and other things. There is some
> overlap and ambiguity that would be great to iron out if we could.
>
>
>
> I think there’s too much to discuss to do it via email, but I’ll take a stab
> at a few things here.
>
>
>
> We’ve been waiting for 6 months for a POC for what you describe below and
> kind of gave up on it. We needed to ship something and couldn’t wait any
> more. If you think your close enough that you can show us at the summit,
> that would be great. We’d be very happy to see it.
>
>
>
> At present, here’s my thinking about some of the things listed below:
>
>
>
> I think sharing the schema at very least would be great. If the versioning
> stuff you have covers everything the app-catalog needs, we should just use
> it rather then coming up with something ourselves. If its not set in stone
> right now, it’s an ideal time to ensure all the features needed are there.
>
>
>
> The root of the tree, as you describe it has some problems that the rest of
> the tree doesn’t. Its global and unauthenticated. It has to be Internet
> scale, not just single cloud scale. Like you said, glance supports features
> for authorization. But those may be anti-features for the root that may
> cause excessive overhead when used as a root, unauthenticated source. The
> same is true of Searchlight. Searchlight buys you
> elasticsearch+authorization/multitenancy, which the root catalog’s don’t
> need. They just need eleasticsearch, so Searchlight may add complexity
> without any benefit. Don’t get me wrong. I think Searchlight is awesome,
> just maybe not for https://apps.openstack.org.
>
>
>
> Not saying any of that is true, just possible reasons why we may not want to
> use glance’s implementation at the root. We have to carefully consider
> things.
>
>
>
> If that code base can’t be shared, what may make more sense (I’m not sure.
> Just laying options out), is to share a glance v3 artifact compatible api
> that glance can point at for the root? Or a subset of the v3 api that makes
> sense to both use cases and still supports the tree hierarchy.
>
>
>
> Like you said, we may need to extend the api specification to support some
> of the features that are unique to the app-catalog use cases too. If you’re
> open to it, I think we are too. If we go the route of sharing an api but not
> a server implementation, that may not be necessary though.
>
>
>
> Anyway, thanks for starting the conversation. I think it’s a great thing to
> get going. Can we get together at the summit and discuss further?
>
>
>
> Thanks,
>
> Kevin
>
>
>
>
>
> From: Alexander Tivelkov [mailto:ativel...@mirantis.com]
> Sent: Thursday, October 15, 2015 3:05 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [app-catalog] [glance] [murano] Data Assets API for
> App Catalog
>
>
>
> Hi folks,
>
>
>
> I’ve noticed that the Community Application Catalog has begun to implement
> its own API, and it seems to me that we are going to have some significant
> duplication of efforts with the code which has already been implemented in
> Glance as Artifact Repository initiative (also known as Glance V3).
>
> From the very beginning of the App Catalog project (and I’ve been involved
> in it since February) I’ve been proposing to use Glance as its backend,
> because from my point of view it covers like 90% of the needed
> functionality. But it looks like we have some kind of miscommunication here,
> as I am getting some confusing questions and assumptions, like the vision of
> Glance V3 being dedicated backend for Murano (which is definitely
> incorrect).
>
> So, I am writing the email to clarify my vision of what Glance V3 is and how
> its features may be used to provide the REST API for Community App Catalog.
>
>
>
> 1.  Versioned schema
>
> First of all, Glance V3 operates on entities called “artifacts”, and these
> ones perfectly map to the Data Assets of

Re: [openstack-dev] [neutron][stable] proactive backporting

2015-10-16 Thread Sean M. Collins

On Fri, Oct 16, 2015 at 11:36:13AM EDT, Salvatore Orlando wrote:
> It might also make sense to ask contributors to resume the habit of tagging
> bugs with 'backport-potential' even if not in the RC period.

I like this idea because it'll make Ihar's job easier :)

-- 
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] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

2015-10-16 Thread Sergii Golovatiuk

Tests should be in plugin

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

On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier 
wrote:

> Hello Alexey,
>
> On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin 
> wrote:
>
>> Hello Simon!
>>
>> We are going to remove plugins' functional tests from fuel-qa because
>> this tests don't use for our plugins CI process.
>>
>
> And where are the existing tests going to be stored then?
>
> Thanks,
> Simon
>
>
>>
>> __
>> OpenStack Development Mailing 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] [mistral][liberty][release] Mistral Liberty release (1.0.0) available

Hi,

Mistral Official Liberty release versioned as 1.0.0 is now available.

Look at the release page at Launchpad ([0]) to see release notes and detailed 
information about implemented blueprints and fixed bugs. There you can also 
download project tarballs (also published on pypi).

Note that official Mistral documentation is now available at [1]. 

P.S. Team, thank you for your hard work! Looking forward to see you at the 
summit.

[0] https://launchpad.net/mistral/liberty/1.0.0 

[1] http://docs.openstack.org/developer/mistral/ 


Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [app-catalog] [glance] [murano] Data Assets API for App Catalog

2015-10-16 Thread Christopher Aedo

On Thu, Oct 15, 2015 at 3:04 AM, Alexander Tivelkov
 wrote:
> Hi folks,
>
> I’ve noticed that the Community Application Catalog has begun to implement
> its own API, and it seems to me that we are going to have some significant
> duplication of efforts with the code which has already been implemented in
> Glance as Artifact Repository initiative (also known as Glance V3).
> From the very beginning of the App Catalog project (and I’ve been involved
> in it since February) I’ve been proposing to use Glance as its backend,
> because from my point of view it covers like 90% of the needed
> functionality. But it looks like we have some kind of miscommunication here,
> as I am getting some confusing questions and assumptions, like the vision of
> Glance V3 being dedicated backend for Murano (which is definitely
> incorrect).
> So, I am writing the email to clarify my vision of what Glance V3 is and how
> its features may be used to provide the REST API for Community App Catalog.
>
> 1.  Versioned schema
> First of all, Glance V3 operates on entities called “artifacts”, and these
> ones perfectly map to the Data Assets of community app catalog. The
> artifacts are strongly typed: there are artifact types for murano packages,
> glance images, heat templates - and there may be (and will be) more. Each
> artifact type is represented by a plugin, defining the schema of objects’
> data and metadata and - optionally - custom logic. So, this thing is
> extensible: when a new type of asset needs to be added to a catalog it can
> be done really quickly by just defining the schema and putting that schema
> into a plugin. Also, these plugins are versioned, so the possible changes in
> the schema are handled properly.
>
> 2. Generic properties
> Next, all the artifact types in Glance V3 have some generic metadata
> properties (i.e. part of the schema which is common for all the types),
> including the name, the version, description, authorship information and so
> on. This also corresponds to the data schema of community app catalog. The
> mapping is not 1:1, but we can work together on this to make sure that these
> generic properties match the expectations of the catalog.
>
> 3. Versioning
> Versions are very important for catalogs of objects, so Glance V3 was
> initially designed keeping versioning questions in mind: each artifact has a
> semver-based version assigned, so the artifacts having the same name but
> different versions are grouped into the proper sequences. API is able to
> query artifacts based on their version spec, e.g. it is possible to fetch
> the latest artifact with the name “foo” having the version greater than 2.1
> and less than 3.5.7 - or any other version spec, similar to pip or any other
> similar tool. As far as I know, community app catalog does not have such
> capabilities right now - and I strongly believe that it is really a must
> have feature for a catalog to be successful. At least it is absolutely
> mandatory for Murano packages, which are the only “real apps” among the
> asset types right now.
>
> 4. Cross artifact dependencies
> Glance V3 also has the dependency relations from the very beginning, so they
> may be defined as part of artifact type schema. As a result, an artifact may
> “reference” any number of other artifacts with various semantic. For
> example, murano package may define a set of references to other murano
> packages and call it “requires” - and this will act similar to the
> requirements of a python package. Similar properties may be defined for heat
> templates and glance images - they may reference each other with various
> semantics.
> Of course, the definitions of such dependencies may be done internally
> inside the packages, so they may be resolved locally by the service which is
> going to use it, but letting the catalog know about them will allow us to do
> the import-export operations for any given artifacts and its dependencies
> automatically, only by the means of the catalog itself.
>
> 5. Search and filtering API
> Right now Glance V3 API is in experimental state (we plan to stabilize it
> during the Mitaka cycle), but it already provides quite good capabilities to
> discover things. It can search artifacts by their type, name and
> (optionally) aforementioned version specs, by tag or even by arbitrary set
> of metadata properties. We have plans to integrate Glance V3 with the
> Searchlight project to have even more index and search capabilities using
> its elastic search engine.
>
> 6. Data storage
> As you probably know, Glance does not own the binary data of its images.
> Instead, it provides an abstraction of the backend storage, which may be
> swift, ceph, s3 or something else. The same approach is used in Glance V3
> for artifacts data, but with more per-type control: particular artifact
> types may be configured independently to store their blobs in different
> backends. This may be of use for Community App Catalog which

Re: [openstack-dev] [all][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

Excerpts from Jeremy Stanley's message of 2015-10-16 20:02:15 +:
> On 2015-10-16 15:27:30 -0400 (-0400), Doug Hellmann wrote:
> > Maybe we can combine the ideas. Define an option with a default value
> > based on an environment variable, and then projects can override it if
> > they care about having the doc build generate that link correctly
> > outside of CI.
> > 
> > What do I need to do to expose the environment variable?
> 
> Within the calling environment for the jobs on our workers, there is
> a $ZUUL_PROJECT variable we can use to get this information.
> However, the job is really just a shell script
> (jenkins/scripts/run-docs.sh in openstack-infra/project-config)
> where we can set any new environment variable oslosphinx cares about
> to that value quite trivially. The envvar name should ultimately
> just be something which makes sense for oslosphinx outside of the CI
> system as well.

I realized as I went to implement this that because we run through
tox, we would also need to update every tox.ini to allow the
environment variable to be passed through. If we're going to do
that, we might as well just update the conf.py directly. I'll add
an option that can be set there.

Doug

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

Re: [openstack-dev] [magnum] Failed to create swarm baywithfedora-21-atomic-5-d181.qcow2

2015-10-16 Thread Ton Ngo

Hi Mars,
Your paste shows that the docker service is not starting, and all the
following services like swarm-agent fails because of the dependency.  The
error message INVALIDARGUMENT seems odd, I have seen elsewhere but not with
docker.  If you log into the node, you can check the docker command itself,
like:
docker --help
Or manually run the full command as done in the service:
/usr/bin/docker -d -H fd:// -H tcp://0.0.0.0:2375 --tlsverify
--tlscacert="/etc/docker/ca.crt" --tlskey="/etc/docker/server.key"
--tlscert="/etc/docker/server.crt" --selinux-enabled --storage-driver
devicemapper --storage-opt dm.fs=xfs --storage-opt
dm.datadev=/dev/mapper/atomicos-docker--data --storage-opt
dm.metadatadev=/dev/mapper/atomicos-docker--meta

Ton,



From:   Hongbin Lu 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   10/16/2015 01:05 PM
Subject:Re: [openstack-dev] [magnum] Failed to create swarm bay
withfedora-21-atomic-5-d181.qcow2



Hi Mars,

I cannot reproduce the error. My best guess is that your VMs don’t have
external internet access (Could you verify it by ssh into one of your VM
and type “curl openstack.org” ?). If not, please create a bug to report the
error (https://bugs.launchpad.net/magnum).

Thanks,
Hongbin

From: Mars Ma [mailto:wenc...@gmail.com]
Sent: October-16-15 2:37 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum] Failed to create swarm bay with
fedora-21-atomic-5-d181.qcow2

Hi,

I used image fedora-21-atomic-5-d181.qcow2 to create swarm bay , but the
bay went to failed status with status reason: Resource CREATE failed:
WaitConditionFailure: resources.swarm_nodes.resources
[0].resources.node_agent_wait_condition: swarm-agent service failed to
start.
debug inside swarm node, found that docker failed to start, lead to
swarm-agent and swarm-manager services failed to start.
[fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ docker -v
Docker version 1.8.1.fc21, build 32b8b25/1.8.1

detailed debug log, I pasted here :
http://paste.openstack.org/show/476450/




Thanks & Best regards !
Mars Ma
__
OpenStack Development Mailing 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/liberty] [requirements]/[oslo] ceilometer jobs failing.

2015-10-16 Thread Tony Breeds

On Fri, Oct 16, 2015 at 03:32:21PM -0400, Doug Hellmann wrote:
> Excerpts from Tony Breeds's message of 2015-10-16 22:21:27 +1100:
> > Hi All,
> > We have an issue for any review that causes a new commit to ceilometer, 
> > it
> > will fail with[1]:
> > 
> > ValueError: git history requires a target version of
> > pbr.version.SemanticVersion(5.0.1), but target version is
> > pbr.version.SemanticVersion(5.0.0)
> > 
> > Switching to post-versioning[2] can't land because of [3]  The fix for that 
> > is
> > to ban 2.6.1 (and 2.6.0) from requirements.  That can't land because of[1],
> > and we've come full circle.
> 
> The fix to allow global requirements changes to land in stable/liberty
> is in https://review.openstack.org/235924

Ahh thanks Doug.  That's a neat fix.  I wasn't sure why integration.sh
and the clone of a clone.  Now I understand, just as it's gone ;P
 
> After that has merged, https://review.openstack.org/233854 will block
> oslo.messaging 2.6 from stable/liberty.

We actually need both https://review.openstack.org/233854 
and https://review.openstack.org/#/c/235536  to land at this point.

as 2.6.0 and 2.6.1 are problematic.
 
> Then we have https://review.openstack.org/235815 to strip the
> pre-versioning setting and fold in the requirements updates for
> ceilometer.

I'll address the review feedback  and republish.
 
> We need to land the patches in that order.
> 
> > I can't use Depends-On as the patches in each repo need to land at the same
> > time.  So I tried the "obvious squash" patch at [4], but that isn't going to
> > work because of the sensible requirements checking.
> > 
> > The only way it fix this I can think of is to release 2.6.2 of 
> > oslo.messaging
> > with the fixes needed by ceilometer (which have merged).
> > 
> > I can think of a couple of rather terrible ways to hack around this but lets
> > not go there unless there is a good reason to not release 2.6.2
> 
> Releasing 2.6.2 would also be OK, if that happens first.

Cool.  I'd hope we can land the 4 patches required before Monday.

Yours Tony.


pgpTD5C7Zscsn.pgp
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] [all][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

Excerpts from Jeremy Stanley's message of 2015-10-16 17:49:00 +:
> On 2015-10-16 12:59:29 -0400 (-0400), Doug Hellmann wrote:
> > Excerpts from Jeremy Stanley's message of 2015-10-16 15:46:33 +:
> [...]
> > >   * You never know what the form of a developer's local origin URL
> > > might be, so this is likely locally broken for a lot of people
> > > anyway. For example, I usually clone with a .git extension on
> > > the URL because I'm a pedant (there are plenty of ways this
> > > assumption could go wrong, this is merely one of them).
> > 
> > I wasn't worried about supporting the local build case for this. Do you
> > think we need to?
> [...]
> 
> I suppose not, unless people testing their documentation changes
> locally expect to see that link work. I agree it seems like a bit of
> a corner case.

Sure, it would be fine if it worked, but it doesn't seem like a
priority.

> 
> > > 1.  Check some documented envvar like OPENSTACK_PROJECT_NAME and
> > > expect it to contain something in the form of
> > > /. This way we can explicitly set it in our
> > > CI jobs to an already populated variable like ZUUL_PROJECT which
> > > contains this information.
> > 
> > That sounds like way more work than is useful for such a small
> > feature.
> 
> I mainly bring it up because the project name is known to the build
> environment, if only oslosphinx had some means to be told the actual
> value rather than having to separately guess it based on less
> accurate mechanisms.

Maybe we can combine the ideas. Define an option with a default value
based on an environment variable, and then projects can override it if
they care about having the doc build generate that link correctly
outside of CI.

What do I need to do to expose the environment variable?

> 
> > > 2.  If OPENSTACK_PROJECT_NAME is not set, check an optional
> > > extension parameter in doc/source/conf.py so that projects can
> > > explicitly set their source URL (this improves downstream
> > > consumability of the extension).
> > 
> > Defining a config value and updating every project to set it also seemed
> > like more work than the outcome warranted. Defining the option is easy,
> > but that's a lot of project patches.
> [...]
> 
> However, it does make it possible for projects to use this feature
> in oslosphinx even if they're not using our hosting infrastructure.
> Again, probably a corner case so not a necessary usage for us to
> support I guess.

__
OpenStack Development Mailing 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] [release] opening stable/liberty

Excerpts from Renat Akhmerov's message of 2015-10-17 01:40:38 +0600:
> Doug,
> 
> I saw your email after I actually released Mistral Liberty version out of 
> stable/liberty branch and it has "version = 1.0.0" in setup.cfg. Do I need to 
> remove it and make a minor release?

It looks like you tagged the most recent commit on stable/liberty as
1.0.0, which is OK. The tag and setup.cfg match, so the release should
work fine.

The next thing you should do is commit a patch to that branch to
remove the version line from setup.cfg. That will switch you to
post-versioning on the branch, which will allow you to merge other
changes there and then just use tags for point releases.

Doug

> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> > On 16 Oct 2015, at 00:30, Doug Hellmann  wrote:
> > 
> > One of the first steps for opening stable/liberty is to update the
> > version settings in the branches to no longer use pre-versioning.
> > Thierry submitted a bunch of patches to projects [0], and some are
> > merging now.
> > 
> > Others are running into test failures, though, and need attention from
> > project teams. We need release liaisons to look at them, or find someone
> > to look at them, and take over the patches to add whatever fixes are
> > needed so we can land them.
> > 
> > Please respond to this thread if you're taking over the patch for your
> > project so we know who is working on each.
> > 
> > Doug
> > 
> > [0] 
> > https://review.openstack.org/#/q/branch:stable/liberty+topic:next-liberty-stable,n,z
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing 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][stable] proactive backporting

2015-10-16 Thread Edgar Magana

+ 2 and total support for it.

Looking forward to reviewing the first set of them.

Edgar 



On 10/16/15, 5:33 AM, "Ihar Hrachyshka"  wrote:

>Hi all,
>
>I’d like to introduce a new initiative around stable branches for neutron 
>official projects (neutron, neutron-*aas, python-neutronclient) that is 
>intended to straighten our backporting process and make us more proactive in 
>fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a known 
>bug hits a user that consumes stable branches, but backport fixes in advance 
>quickly after they hit master.
>
>The idea is simple: every Fri I walk thru the new commits merged into master 
>since last check; produce lists of bugs that are mentioned in 
>Related-Bug/Closes-Bug; paste them into:
>
>https://etherpad.openstack.org/p/stable-bug-candidates-from-master
>
>Then I click thru the bug report links to determine whether it’s worth a 
>backport and briefly classify them. If I have cycles, I also request backports 
>where it’s easy (== a mere 'Cherry-Pick to' button click).
>
>After that, those interested in maintaining neutron stable branches can take 
>those bugs one by one and handle them, which means: checking where it really 
>applies for backport; creating backport reviews (solving conflicts, making 
>tests pass). After it’s up for review for all branches affected and 
>applicable, the bug is removed from the list.
>
>I started on that path two weeks ago, doing initial swipe thru all commits 
>starting from stable/liberty spin off. If enough participants join the 
>process, we may think of going back into git history to backport interesting 
>fixes from stable/liberty into stable/kilo.
>
>Don’t hesitate to ask about details of the process, and happy backporting,
>
>Ihar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

> On 16 Oct 2015, at 13:02, WANG, Ming Hao (Tony T) 
>  wrote:
> 
> Another question is:
> If I want to call a user-defined script in Mistral, what action should be 
> used?
> Still use “ssh std_action”?

Yes, std.ssh action or std.ssh_proxied that allows to ssh through an VM with a 
floating ip (ssh gateway) to other VMs. “std.ssh_proxied” was just added 
recently.

Renat Akhmerov
@ Mirantis Inc.

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

Re: [openstack-dev] [neutron][stable] proactive backporting

2015-10-16 Thread Kevin Benton

We can't put in code and just hope for testing later. The tests are even
more important in back-ports because there could be unexpected differences
in the stable branch that make the patch not work correctly.

However, we do need to make sure that people aren't complaining about the
testing methodology in the back-ports because it's too late for that.

On Fri, Oct 16, 2015 at 2:23 PM, Fox, Kevin M  wrote:

> It would also help if the process could split out bug fixes from unit
> tests. I had a bug fix get stuck while the unit tests were bikesheded for a
> while, and then the delay of not getting quickly backported to the stable
> branches then kicked in. All the while I had to patch production clouds by
> hand with a non upstreamed fix. I'm all for having unit tests to ensure the
> bugs don't creep back in, but regression bugs should be fixed as quickly as
> possible.
>
> Thanks,
> Kevin
> 
> From: Edgar Magana [edgar.mag...@workday.com]
> Sent: Friday, October 16, 2015 2:04 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][stable] proactive backporting
>
> + 2 and total support for it.
>
> Looking forward to reviewing the first set of them.
>
> Edgar
>
>
>
> On 10/16/15, 5:33 AM, "Ihar Hrachyshka"  wrote:
>
> >Hi all,
> >
> >I’d like to introduce a new initiative around stable branches for neutron
> official projects (neutron, neutron-*aas, python-neutronclient) that is
> intended to straighten our backporting process and make us more proactive
> in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a
> known bug hits a user that consumes stable branches, but backport fixes in
> advance quickly after they hit master.
> >
> >The idea is simple: every Fri I walk thru the new commits merged into
> master since last check; produce lists of bugs that are mentioned in
> Related-Bug/Closes-Bug; paste them into:
> >
> >https://etherpad.openstack.org/p/stable-bug-candidates-from-master
> >
> >Then I click thru the bug report links to determine whether it’s worth a
> backport and briefly classify them. If I have cycles, I also request
> backports where it’s easy (== a mere 'Cherry-Pick to' button click).
> >
> >After that, those interested in maintaining neutron stable branches can
> take those bugs one by one and handle them, which means: checking where it
> really applies for backport; creating backport reviews (solving conflicts,
> making tests pass). After it’s up for review for all branches affected and
> applicable, the bug is removed from the list.
> >
> >I started on that path two weeks ago, doing initial swipe thru all
> commits starting from stable/liberty spin off. If enough participants join
> the process, we may think of going back into git history to backport
> interesting fixes from stable/liberty into stable/kilo.
> >
> >Don’t hesitate to ask about details of the process, and happy backporting,
> >
> >Ihar
> __
> OpenStack Development Mailing 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
>



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

[openstack-dev] [Fuel] deployment tests for fuel-library switched to Liberty-based ISO

2015-10-16 Thread Aleksandra Fedorova

Hi, everyone, please be informed,

Liberty-based Fuel ISO image now passes Build Verification Test [1].

Therefore both deployment tests [2] and [3] for fuel-library
repository are now switched from Kilo to Liberty-based ISO.


Latest nightly build for 8.0 ISO with Liberty OpenStack is available
at https://ci.fuel-infra.org/.


[1] https://ci.fuel-infra.org/job/8.0.fuel_community.ubuntu.bvt_2/16/
[2] 
https://ci.fuel-infra.org/job/master.fuel-library.pkgs.ubuntu.neutron_vlan_ha/
[3] https://ci.fuel-infra.org/job/fuellib_review_pkgs_master_node/

-- 
Aleksandra Fedorova
Fuel CI Engineer
bookwar

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

Re: [openstack-dev] [Fuel] deployment tests for fuel-library switched to Liberty-based ISO

2015-10-16 Thread Mike Scherbakov

We just discussed it during the lunch with D.Borodaenko :)

Thanks a lot!

On Fri, Oct 16, 2015 at 12:48 PM Aleksandra Fedorova 
wrote:

> Hi, everyone, please be informed,
>
> Liberty-based Fuel ISO image now passes Build Verification Test [1].
>
> Therefore both deployment tests [2] and [3] for fuel-library
> repository are now switched from Kilo to Liberty-based ISO.
>
>
> Latest nightly build for 8.0 ISO with Liberty OpenStack is available
> at https://ci.fuel-infra.org/.
>
>
> [1] https://ci.fuel-infra.org/job/8.0.fuel_community.ubuntu.bvt_2/16/
> [2]
> https://ci.fuel-infra.org/job/master.fuel-library.pkgs.ubuntu.neutron_vlan_ha/
> [3] https://ci.fuel-infra.org/job/fuellib_review_pkgs_master_node/
>
> --
> Aleksandra Fedorova
> Fuel CI Engineer
> bookwar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

2015-10-16 Thread Jeremy Stanley

On 2015-10-16 15:27:30 -0400 (-0400), Doug Hellmann wrote:
> Maybe we can combine the ideas. Define an option with a default value
> based on an environment variable, and then projects can override it if
> they care about having the doc build generate that link correctly
> outside of CI.
> 
> What do I need to do to expose the environment variable?

Within the calling environment for the jobs on our workers, there is
a $ZUUL_PROJECT variable we can use to get this information.
However, the job is really just a shell script
(jenkins/scripts/run-docs.sh in openstack-infra/project-config)
where we can set any new environment variable oslosphinx cares about
to that value quite trivially. The envvar name should ultimately
just be something which makes sense for oslosphinx outside of the CI
system as well.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [magnum] Failed to create swarm bay with fedora-21-atomic-5-d181.qcow2

2015-10-16 Thread Hongbin Lu

Hi Mars,

I cannot reproduce the error. My best guess is that your VMs don’t have 
external internet access (Could you verify it by ssh into one of your VM and 
type “curl openstack.org” ?). If not, please create a bug to report the error 
(https://bugs.launchpad.net/magnum).

Thanks,
Hongbin

From: Mars Ma [mailto:wenc...@gmail.com]
Sent: October-16-15 2:37 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum] Failed to create swarm bay with 
fedora-21-atomic-5-d181.qcow2

Hi,

I used image fedora-21-atomic-5-d181.qcow2 to create swarm bay , but the bay 
went to failed status with status reason: Resource CREATE failed: 
WaitConditionFailure: 
resources.swarm_nodes.resources[0].resources.node_agent_wait_condition: 
swarm-agent service failed to start.
debug inside swarm node, found that docker failed to start, lead to swarm-agent 
and swarm-manager services failed to start.
[fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ docker -v
Docker version 1.8.1.fc21, build 32b8b25/1.8.1

detailed debug log, I pasted here :
http://paste.openstack.org/show/476450/




Thanks & Best regards !
Mars Ma
__
OpenStack Development Mailing 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] [release] opening stable/liberty

Doug,

I saw your email after I actually released Mistral Liberty version out of 
stable/liberty branch and it has "version = 1.0.0" in setup.cfg. Do I need to 
remove it and make a minor release?

Renat Akhmerov
@ Mirantis Inc.



> On 16 Oct 2015, at 00:30, Doug Hellmann  wrote:
> 
> One of the first steps for opening stable/liberty is to update the
> version settings in the branches to no longer use pre-versioning.
> Thierry submitted a bunch of patches to projects [0], and some are
> merging now.
> 
> Others are running into test failures, though, and need attention from
> project teams. We need release liaisons to look at them, or find someone
> to look at them, and take over the patches to add whatever fixes are
> needed so we can land them.
> 
> Please respond to this thread if you're taking over the patch for your
> project so we know who is working on each.
> 
> Doug
> 
> [0] 
> https://review.openstack.org/#/q/branch:stable/liberty+topic:next-liberty-stable,n,z
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

Excerpts from Doug Hellmann's message of 2015-10-16 16:22:55 -0400:
> Excerpts from Jeremy Stanley's message of 2015-10-16 20:02:15 +:
> > On 2015-10-16 15:27:30 -0400 (-0400), Doug Hellmann wrote:
> > > Maybe we can combine the ideas. Define an option with a default value
> > > based on an environment variable, and then projects can override it if
> > > they care about having the doc build generate that link correctly
> > > outside of CI.
> > > 
> > > What do I need to do to expose the environment variable?
> > 
> > Within the calling environment for the jobs on our workers, there is
> > a $ZUUL_PROJECT variable we can use to get this information.
> > However, the job is really just a shell script
> > (jenkins/scripts/run-docs.sh in openstack-infra/project-config)
> > where we can set any new environment variable oslosphinx cares about
> > to that value quite trivially. The envvar name should ultimately
> > just be something which makes sense for oslosphinx outside of the CI
> > system as well.
> 
> I realized as I went to implement this that because we run through
> tox, we would also need to update every tox.ini to allow the
> environment variable to be passed through. If we're going to do
> that, we might as well just update the conf.py directly. I'll add
> an option that can be set there.
> 
> Doug
> 

Here's the change: https://review.openstack.org/236091

Doug

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

Re: [openstack-dev] [stable/liberty] [requirements]/[oslo] ceilometer jobs failing.

Excerpts from Tony Breeds's message of 2015-10-16 22:21:27 +1100:
> Hi All,
> We have an issue for any review that causes a new commit to ceilometer, it
> will fail with[1]:
> 
> ValueError: git history requires a target version of
> pbr.version.SemanticVersion(5.0.1), but target version is
> pbr.version.SemanticVersion(5.0.0)
> 
> Switching to post-versioning[2] can't land because of [3]  The fix for that is
> to ban 2.6.1 (and 2.6.0) from requirements.  That can't land because of[1],
> and we've come full circle.

The fix to allow global requirements changes to land in stable/liberty
is in https://review.openstack.org/235924

After that has merged, https://review.openstack.org/233854 will block
oslo.messaging 2.6 from stable/liberty.

Then we have https://review.openstack.org/235815 to strip the
pre-versioning setting and fold in the requirements updates for
ceilometer.

We need to land the patches in that order.

> I can't use Depends-On as the patches in each repo need to land at the same
> time.  So I tried the "obvious squash" patch at [4], but that isn't going to
> work because of the sensible requirements checking.
> 
> The only way it fix this I can think of is to release 2.6.2 of oslo.messaging
> with the fixes needed by ceilometer (which have merged).
> 
> I can think of a couple of rather terrible ways to hack around this but lets
> not go there unless there is a good reason to not release 2.6.2

Releasing 2.6.2 would also be OK, if that happens first.

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] [Neutron] Design Summit Lighting talks

2015-10-16 Thread Armando M.

Folks,

The session [1] is planned for Thursday at 3.30pm. If you're interested,
please sign up. The time to submit ideas is running out.

Cheers,
Armando

[1] https://etherpad.openstack.org/p/mitaka-neutron-labs-lighting-talks
__
OpenStack Development Mailing 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] Scheduler proposal

2015-10-16 Thread Julien Danjou

On Fri, Oct 16 2015, Joshua Harlow wrote:

> Another idea is to use numpy and start representing filters as linear
> equations, then use something like
> https://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.solve.html#numpy.linalg.solve
> to solve linear equations given some data.
>
> Another idea, turn each filter into a constraint equation (which it sorta is
> anyway) and use a known fast constraint solver on that data...
>
> Lots of ideas here that can be possible, likely endless :)

Already pasted on Twitter, but just in case, Optaplanner:

  
http://community.redhat.com/blog/2014/11/smart-vm-scheduling-in-ovirt-clusters/

-- 
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] [neutron][stable] proactive backporting

2015-10-16 Thread Fox, Kevin M

It would also help if the process could split out bug fixes from unit tests. I 
had a bug fix get stuck while the unit tests were bikesheded for a while, and 
then the delay of not getting quickly backported to the stable branches then 
kicked in. All the while I had to patch production clouds by hand with a non 
upstreamed fix. I'm all for having unit tests to ensure the bugs don't creep 
back in, but regression bugs should be fixed as quickly as possible.

Thanks,
Kevin

From: Edgar Magana [edgar.mag...@workday.com]
Sent: Friday, October 16, 2015 2:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][stable] proactive backporting

+ 2 and total support for it.

Looking forward to reviewing the first set of them.

Edgar



On 10/16/15, 5:33 AM, "Ihar Hrachyshka"  wrote:

>Hi all,
>
>I’d like to introduce a new initiative around stable branches for neutron 
>official projects (neutron, neutron-*aas, python-neutronclient) that is 
>intended to straighten our backporting process and make us more proactive in 
>fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a known 
>bug hits a user that consumes stable branches, but backport fixes in advance 
>quickly after they hit master.
>
>The idea is simple: every Fri I walk thru the new commits merged into master 
>since last check; produce lists of bugs that are mentioned in 
>Related-Bug/Closes-Bug; paste them into:
>
>https://etherpad.openstack.org/p/stable-bug-candidates-from-master
>
>Then I click thru the bug report links to determine whether it’s worth a 
>backport and briefly classify them. If I have cycles, I also request backports 
>where it’s easy (== a mere 'Cherry-Pick to' button click).
>
>After that, those interested in maintaining neutron stable branches can take 
>those bugs one by one and handle them, which means: checking where it really 
>applies for backport; creating backport reviews (solving conflicts, making 
>tests pass). After it’s up for review for all branches affected and 
>applicable, the bug is removed from the list.
>
>I started on that path two weeks ago, doing initial swipe thru all commits 
>starting from stable/liberty spin off. If enough participants join the 
>process, we may think of going back into git history to backport interesting 
>fixes from stable/liberty into stable/kilo.
>
>Don’t hesitate to ask about details of the process, and happy backporting,
>
>Ihar
__
OpenStack Development Mailing 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] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

2015-10-16 Thread Mike Spreitzer

> From: Mike Spreitzer/Watson/IBM@IBMUS
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 10/13/2015 03:39 AM
> Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> questions about configuring DevStack to use Neutron
> 
> > From: "Sean M. Collins" 
> > To: "OpenStack Development Mailing List (not for usage questions)" 
> > 
> > Date: 10/12/2015 11:34 AM
> > Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> > questions about configuring DevStack to use Neutron
> > 
> > On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote:
> > > ..
> > > > > In the section 
> > > > > http://docs.openstack.org/developer/devstack/guides/
> > > > neutron.html#using-neutron-with-a-single-interface
> > > > > there is a helpful display of localrc contents.  It says, among 
other 
> > > > > things,
> > > > > 
> > > > >OVS_PHYSICAL_BRIDGE=br-ex
> > > > >PUBLIC_BRIDGE=br-ex
> > > > > 
> > > > > In the next top-level section, 
> > > > > http://docs.openstack.org/developer/devstack/guides/
> > > > neutron.html#using-neutron-with-multiple-interfaces
> > > > > , there is no display of revised localrc contents and no mention 
of 
> > > > > changing either bridge setting.  That is an oversight, right?
> > > > 
> > > > No, this is deliberate. Each section is meant to be independent, 
since
> > > > each networking configuration and corresponding DevStack 
configuration
> > > > is different. Of course, this may need to be explicitly stated in 
the
> > > > guide, so there is always room for improvement.
> > > 
> > > I am not quite sure I understand your answer.  Is the intent that I 
can 
> > > read only one section, ignore all the others, and that will tellme 
how to 
> > > use DevStack to produce that section's configuration?  If so 
> then it would 
> > > be good if each section had a display of all the necessary localrc 
> > > contents.
> > 
> > Agreed. This is a failure on my part, because I was pasting in only
> > parts of my localrc (since it came out of a live lab environment). 
I've
> > started pushing patches to correct this.
> > 
> > 
> > > I have started over, from exactly the picture drawn at the start of 
the 
> > > doc.  That has produced a configuration that mostly works.  However, 
I 
> > > tried creating a VM connected to the public network, and that failed 
for 
> > > lack of a Neutron DHCP server there.
> > 
> > The public network is used for floating IPs. The L3 agent creates NAT
> > rules to intercept traffic on the public network and NAT it back to a
> > guest instance that has the floating IP allocated to it.
> > 
> > The behavior for when a guest is directly attached to the public
> > network, I sort of forget what happens exactly but I do know that it
> > doesn't work from experience - most likely because the network is not
> > configured as a flat network. It will not receive a DHCP lease from 
the
> > external router.
> > 
> > > I am going to work out how to change 
> > > that, and am willing to contribute an update to this doc.  Wouldyou 
want 
> > > that in this section --- in which case this section needs to specify 
that 
> > > the provider DOES NOT already have DHCP service on the hardware 
network 
> > > --- or as a new section?
> > 
> > No, I think we should maybe have a warning or something that the
> > external network will be used for Floating IPs, and that guest 
instances
> > should not be directly attached to that network.
> > 
> > > > > 
> > > > > Looking at 
> > > > > 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or
> > > , in 
> > > > > former days, the doc now preserved at 
> > > > > http://docs.ocselected.org/openstack-manuals/kilo/networking-
> > > > guide/content/under_the_hood_openvswitch.html
> > > > > ) I see the name br-ex used for $PUBLIC_BRIDGE--- not 
> > > $OVS_PHYSICAL_BRIDGE
> > > > > , right?  Wouldn't it be less confusing if 
> > > > > 
http://docs.openstack.org/developer/devstack/guides/neutron.htmluseda 
> > > 
> > > > > name other than "br-ex" for the exhibited commands that apply to 

> > > > > $OVS_PHYSICAL_BRIDGE?
> > > > 
> > > > No, this is deliberate - br-ex is the bridge that is used for 
external
> > > > network traffic - such as floating IPs and public IP address 
ranges. On
> > > > the network node, a physical interface is attached to br-ex so 
that
> > > > traffic will flow.
> > > > 
> > > > PUBLIC_BRIDGE is a carryover from DevStack's Nova-Network support 
and is
> > > > used in some places, with OVS_PHYSICAL_BRIDGE being used by 
DevStack's
> > > > Neutron support, for the Open vSwitch driver specifically. They 
are two
> > > > variables that for the most part serve the same purpose. Frankly,
> > > > DevStack has a lot of problems with configuration knobs, and
> > > > PUBLIC_BRIDGE and OVS_PHYSICAL_BRIDGE is just a symptom.
> > > 
> > > Ah, thanks, that helps.

[openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

2015-10-16 Thread WANG, Ming Hao (Tony T)

Dear Mistral developers and testers,

We have developed some Ansible playbooks for operation automation, and we are 
investigating if we can change the automation engine from Ansible to Mistral 
since Mistral has powerful workflow control.
Could you please help to provide how to let Mistral call Ansible playbook or 
Ansible module?
My understanding is to use ssh std_action to let Mistral access Ansible server 
to call Ansible playbook/modules since Mistral ad-hoc action must base on an 
existing system action.

Another question is:
If we install Mistral and Ansible on a same server, is it possible to simplify 
it?

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

[openstack-dev] [magnum] Failed to create swarm bay with fedora-21-atomic-5-d181.qcow2

2015-10-16 Thread Mars Ma

Hi,

I used image fedora-21-atomic-5-d181.qcow2 to create swarm bay , but the
bay went to failed status with status reason: Resource CREATE failed:
WaitConditionFailure:
resources.swarm_nodes.resources[0].resources.node_agent_wait_condition:
swarm-agent service failed to start.
debug inside swarm node, found that docker failed to start, lead to
swarm-agent and swarm-manager services failed to start.
[fedora@sw-d7cum4a5z5a-0-dx4eksy72u4q-swarm-node-3d7bwzm7fso7 ~]$ docker -v
Docker version 1.8.1.fc21, build 32b8b25/1.8.1

detailed debug log, I pasted here :
http://paste.openstack.org/show/476450/




Thanks & Best regards !
Mars Ma
__
OpenStack Development Mailing 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] [Cross-posting] Announcement: OpenStack India Online Meetup

2015-10-16 Thread OpenStack India Online

Greetings,


It gives me immense pleasure to announce a well deserved Online Meetup
place for all OpenStack community members in India. With the ever growing
participation to use, evaluate and contribute to OpenStack, the community
in India is growing at a very fast pace. With the large geographical
diversity of physical meetup places (and travel costs involved for
attending meetups), there needs a mechanism for all to collaborate, share
our ideas and a place to look at if we miss anything with all the real
world complexities involved.

I hereby invite everyone interested to share any tini-tiny bit they want to
community members to know to join us at the URL provided below with their
interest and we will make sure there will be event scheduled for you to
collaborate with those who are interested.

Feel free to shoot direct mail to the mail 
with any suggesions/queries you might have.


We all #love #OpenStack. Lets make the community stronger.

*Join Us : *http://goo.gl/forms/HEF5e8qBBV

*Follow us on Social Networks*

*Twitter : *https://twitter.com/OpenStackINOnl
YouTube: https://www.youtube.com/channel/UCNEMU-OZiFWgrl8Qs5Tut0g
Facebook : https://www.facebook.com/openstackindiaonline
__
OpenStack Development Mailing 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] [packaging] liberty doesn't have caps on deps

2015-10-16 Thread Thierry Carrez

Robert Collins wrote:
> [...]
> BUT: we haven't (ever!) tested that the lowest versions we specify
> work. When folk know they are adding a hard dependency on a version we
> do raise the lower versions, but thats adhoc and best effort today.
> I'd like to see a lower-constraints.txt reflecting the oldest version
> that works across all of OpenStack (as a good boundary case to test) -
> but we need to fix pip first to teach it to choose lower versions over
> higher versions (https://github.com/pypa/pip/issues/3188 - I thought
> I'd filed it previously but couldn't find it...)
> 
> More generally, we don't [yet] have the testing setup to test multiple
> versions on an ongoing basis, so we can't actually make any statement
> other than 'upper-constraints.txt is known to work'. Note: before
> constraints we couldn't even make *that* statement. The statement we
> could make then was 'if you look up the change in gerrit and from that
> the CI dvsm test run which got through the gate, then you can
> figureout *a* version of the dependencies that worked.

And that is the critical bit. The system we had in kilo and before may
appear to be more practical to interpret downstream, but the assertions
it was making were mostly untested. So the capping was a convenient
illusion: things beyond the cap may be working, and things below the cap
could actually be broken. At least the upper-constraints expresses
clearly the combination that works and was tested. Combined with the
uncapped requirements (which express what *should* be working, to the
best of our knowledge), they make a more accurate, albeit admittedly
more complex, set of information for downstream packagers.

-- 
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] [Cinder] New extension API for detecting cinder-backup ?

2015-10-16 Thread Duncan Thomas

I think option 2 is the better one, and we can just call it something else
other than capabilities. Available_services or similar
On 16 Oct 2015 11:05, "Ramakrishna, Deepti" 
wrote:

> Hi,
>
>
>
> We need a way to let Horizon know about the presence of cinder-backup
> service so that it can enable the volume backup operations in the UI (
> https://bugs.launchpad.net/cinder/+bug/1334856).
>
>
>
> The backup action does not have any restrictions on who can perform it as
> evidenced by the following policy in etc/cinder/policy.json
> :
>
> "backup:create" : ""
>
>
>
> However, the only API that can tell Horizon about the existence of this
> service, namely the "os-services" API extension (that corresponds to the 
> "cinder
> service-list" client command) is admin-only:
>
> "volume_extension:services:index": "rule:admin_api"
>
>
>
> Today, Horizon uses
>  a
> config setting "enable_backup", that needs to be manually set in order to
> enable backup functionality in Horizon. We need a way for Horizon to figure
> this out itself, programmatically.
>
>
>
> I can think of two ways:
>
>1. Modify the services:index action to take
>a details=true/false parameter (http://
>{cinder-endpoint}/v2/{tenant-id}/os-services*?details=false*). And
>define different policies for detail=true(admin_api)
>and detail=false ("" i.e. unrestricted).
>
>
>- "volume_extension:services:index_with_details": "rule:admin_api"
>   - "volume_extension:services:index_without_details": "”
>1. Raise the abstraction level by creating a Cinder API extension that
>returns the list of "service capabilities". That is, the list of
>functionality that the cinder service supports. This will return only
>"volume backup" for now but can be augmented as new capabilities are added
>to Cinder.
>
>
>
> I don't know if #1 can be implemented in a backward compatible way and
> also whether there is precedence for splitting the policy of a single API
> call based on parameters.
>
> #2 seems the traditional way to do it, but I am afraid that "service
> capabilities" terminology clashes with existing "volume capabilities"
> extension
> ,
> which has a different purpose.
>
>
>
> I would appreciate any input on this.
>
>
>
> Thanks,
>
> Deepti
>
>
>
> __
> OpenStack Development Mailing 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] Scheduler proposal

2015-10-16 Thread Clint Byrum

Excerpts from Ed Leafe's message of 2015-10-15 11:56:24 -0700:
> Wow, I seem to have unleashed a bunch of pent-up frustration in the 
> community! It's great to see everyone coming forward with their ideas and 
> insights for improving the way Nova (and, by extension, all of OpenStack) can 
> potentially scale.
> 
> I do have a few comments on the discussion:
> 
> 1) This isn't a proposal to simply add some sort of DLM to Nova as a magic 
> cure-all. The concerns about Nova's ability to scale have to do a lot more 
> with the overall internal communication design.
> 

In this, we agree.

> 2) I really liked the comment about "made-up numbers". It's so true: we are 
> all impressed by such examples of speed that we sometimes forget whether 
> speeding up X will improve the overall process to any significant degree. The 
> purpose of my original email back in July, and the question I asked at the 
> Nova midcycle, is if we could get some numbers that would be a target to 
> shoot for with any of these experiments. Sure, I could come up with a test 
> that shows a zillion transactions per second, but if that doesn't result in a 
> cloud being able to schedule more efficiently, what's the point?
>

Speed is only 1 dimension. Efficiency and simplicity are two others that
I think are harder to quantify, but are also equally important in any
component of OpenStack.

> 3) I like the idea of something like ZooKeeper, but my concern is how to 
> efficiently query the data. If, for example, we had records for 100K compute 
> nodes, would it be possible to do the equivalent of "SELECT * FROM resources 
> WHERE resource_type = 'compute' AND free_ram_mb >= 2048 AND …" - well, you 
> get the idea. Are complex data queries possible in ZK? I haven't been able to 
> find that information anywhere.
>

You don't do complex queries, because you have all of the data in RAM,
in an efficient in-RAM format. Even if each record is 50KB, we can do
100,000 of them in 5GB. That's a drop in the bucket.

> 4) It is true that even in a very large deployment, it is possible to keep 
> all the relevant data needed for scheduling in memory. My concern is how to 
> efficiently search that data, much like in the ZK scenario.
> 

There are a bunch of ways to do this. My favorite is to have filter
plugins in the scheduler define what they need to index, and then
build a B-tree for each filter as each record arrives in the main data
structure. When scheduling requests come in, they simply walk through
each B-tree and turn that into a set. Then read each piece of the set
out of the main structure and sort based on whichever you want (less
full for load balancing, most full for efficient stacking).

> 5) Concerns about Cassandra running with OpenJDK instead of the Oracle JVM 
> are troubling. I sent an email about this to one of the people I know at 
> DataStax, but so far have not received a response. And while it would be 
> great to have people contribute to OpenJDK to make it compatible, keep in 
> mind that that would be an ongoing commitment, not just a one-time effort.
> 

There are a few avenues to success with Cassandra but I don't think any
of them pass very close to OpenStack's current neighborhood.

> 6) I remember discussions back in the Austin-Bexar time frame about what 
> Thierry referred to as 'flavor-based schedulers', and they were immediately 
> discounted as not sophisticated enough to handle the sort of complex 
> scheduling requests that were expected. I'd be interested in finding out from 
> the big cloud providers what percentage of their requests would fall into 
> this simple structure, and what percent are more complicated than that. 
> Having hosts listening to queues that they know they can satisfy removes the 
> raciness from the process, although it would require some additional handling 
> for the situation where no host accepts the request. Still, it has the 
> advantage of being dead simple. Unfortunately, this would probably require a 
> bigger architectural change than integrating Cassandra into the Scheduler 
> would.
> 

No host accepting the request means your cloud is, more or less, full. If
you have flavors that aren't proper factors of smaller flavors, this
will indeed happen even when it isn't 100% utilized. If you have other
constraints that you allow your users to specify, then you are letting
them dictate how your hardware is utilized, which I think is a foolhardy
business decision. This is no different than any other manufacturing batch
size problem: sometimes parts of your process are under utilized, and
you have to make choices about rejecting certain workloads if they will
end up costing you more than you're willing to pay for the happy customer.

Note that the "efficient stacking" model I talked about can't really
work in the queue-based approach. If you want to fill up the most full
hosts before filling more, you need some awareness of what host is most
full and the compute nodes can't really

Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

2015-10-16 Thread WANG, Ming Hao (Tony T)

Another question is:
If I want to call a user-defined script in Mistral, what action should be used?
Still use "ssh std_action"?

Thanks in advance,
Tony

From: WANG, Ming Hao (Tony T) [mailto:tony.a.w...@alcatel-lucent.com]
Sent: Friday, October 16, 2015 2:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) 
in Mistral

Dear Mistral developers and testers,

We have developed some Ansible playbooks for operation automation, and we are 
investigating if we can change the automation engine from Ansible to Mistral 
since Mistral has powerful workflow control.
Could you please help to provide how to let Mistral call Ansible playbook or 
Ansible module?
My understanding is to use ssh std_action to let Mistral access Ansible server 
to call Ansible playbook/modules since Mistral ad-hoc action must base on an 
existing system action.

Another question is:
If we install Mistral and Ansible on a same server, is it possible to simplify 
it?

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

[openstack-dev] [Glance] Summit schedule uplodaded


Greetings

Glance's schedule for the Mitaka summit is now complete. As mentioned
in our meeting yesterday, the schedule has been uploaded to
sched.org[0].

I'd like to encourage everyone (especially moderators) to check their
schedules and make sure there are no conflicts.

If you have another proposal or topic you'd like to discuss, please,
let us know. There are sessions that could use just 20 mins, which
means we could fit something else in the schedule.

Thanks everyone,
Flavio

[0] http://mitakadesignsummit.sched.org/type/glance#.ViCgvc-1RZK

--
@flaper87
Flavio Percoco


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

[openstack-dev] [Glance] Mitaka spec freeze proposal


Hi Glancers,

Among the things we'd like to give a try to during Mitaka, we also
have having a spec freeze. This was discussed in the latest drivers
meeting[0] and you can find some extra details below.

The freeze will happen after M-1 is cut and before M-2 is out. To be
more precise and allow for scheduling work, we've picked exact dates
for this freeze. The freeze will be on the week of November 28th and
December 1st. This, according to the OpenStack release schedule[1],
will happen 14 weeks before the Mitaka release.

These freeze will allow for exceptions to be proposed. However, such
exceptions must be compliant with the cycle priorities and achievable
in the remaining time for development (using the Feature Freeze as the
final date for it). Other specs will have to be targetted to the N
release.

Please, provide feedback and let us know what you think
Flavio

[0] 
http://eavesdrop.openstack.org/meetings/glance_drivers/2015/glance_drivers.2015-10-13-14.01.log.html
[1] https://wiki.openstack.org/wiki/Mitaka_Release_Schedule

--
@flaper87
Flavio Percoco


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

[openstack-dev] [Cinder] New extension API for detecting cinder-backup ?

2015-10-16 Thread Ramakrishna, Deepti

Hi,

We need a way to let Horizon know about the presence of cinder-backup service 
so that it can enable the volume backup operations in the UI 
(https://bugs.launchpad.net/cinder/+bug/1334856).

The backup action does not have any restrictions on who can perform it as 
evidenced by the following policy in 
etc/cinder/policy.json:
"backup:create" : ""

However, the only API that can tell Horizon about the existence of this 
service, namely the "os-services" API extension (that corresponds to the 
"cinder service-list" client command) is admin-only:
"volume_extension:services:index": "rule:admin_api"

Today, Horizon 
uses a config 
setting "enable_backup", that needs to be manually set in order to enable 
backup functionality in Horizon. We need a way for Horizon to figure this out 
itself, programmatically.

I can think of two ways:

  1.  Modify the services:index action to take a details=true/false parameter 
(http://{cinder-endpoint}/v2/{tenant-id}/os-services?details=false). And define 
different policies for detail=true(admin_api) and detail=false ("" i.e. 
unrestricted).

 *   "volume_extension:services:index_with_details": "rule:admin_api"
 *   "volume_extension:services:index_without_details": ""
  1.  Raise the abstraction level by creating a Cinder API extension that 
returns the list of "service capabilities". That is, the list of functionality 
that the cinder service supports. This will return only "volume backup" for now 
but can be augmented as new capabilities are added to Cinder.

I don't know if #1 can be implemented in a backward compatible way and also 
whether there is precedence for splitting the policy of a single API call based 
on parameters.
#2 seems the traditional way to do it, but I am afraid that "service 
capabilities" terminology clashes with existing "volume capabilities" 
extension,
 which has a different purpose.

I would appreciate any input on this.

Thanks,
Deepti

__
OpenStack Development Mailing 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] [release] establishing release liaisons for mitaka


On 14/10/15 11:25 -0400, Doug Hellmann wrote:

As with the other cross-project teams, the release management team
relies on liaisons from each project to be available for coordination of
work across all teams. It's the start of a new cycle, so it's time to
find those liaison volunteers.

We are working on updating the release documentation as part of the
Project Team Guide. Release liaison responsibilities are documented in
[0], and we will update that page with more details over time.

In the past we have defaulted to having the PTL act as liaison if no
alternate is specified, and we will continue to do that during Mitaka.
If you plan to delegate release work to a liaison, especially for
submitting release requests, please update the wiki [1] to provide their
contact information. If you plan to serve as your team's liaison, please
add your contact details to the page.


Wiki updated for this and all the other liaison roles.

Thanks for the heads up and to all the volunteers,
Flavio



Thanks,
Doug

[0] 
http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons
[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11


On 15/10/15 17:42 +0200, Markus Zoeller wrote:

Zaro wrote:

We are soliciting feedback so please let us know what you think.


For spotting possible trivial bug fixes the new query option "delta"
will be useful. For example: "status:open delta:<100"

Would it be possible to create a "prio" label to help sorting out stuff?
If I understand [1] correctly, we could have something like like:

   [label "Prio"]
   function = NoOp
   value = 0 Undecided
   value = 1 critical
   value = 2 high
   value = 3 trivialfix

For example, this would allow to create a query with

   "status:open label:Prio=3"

to get all reviews for trivial bug fixes.

Nevertheless, I'm looking forward to the upgrade.



+1

In glance we're currently grouping blueprints, bugs and random
patches. It'd be AWESOME, to have a way to tag priorities on patches.

I guess topics could be used but those are overwritten on every new
PS.

Flavio


References:
[1]
https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_custom

Regards,
Markus Zoeller (markus_z)


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


--
@flaper87
Flavio Percoco


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

[openstack-dev] [Neutron][Kuryr]Request for reviews

2015-10-16 Thread 福島拓

Hi,

I'd like to have some reviews on the following patches. They're already
reviewed and approved actually. So if there's nothing to block merging, I'd
appreciate if you could merge them.

libnetwork is changing fast and some of the patches are about to be
outdated. To catch up with its fast update, we need to move forward. We'll
have some exposures in the coming OpenStack Summit and it'd be better to
get the patches merged before that. I'd appreciate your understanding.

https://review.openstack.org/#/q/status:open+project:openstack/kuryr+branch:master+topic:kilo%252Bdocker1.9.0,n,z

And we have some other patches as well.

https://review.openstack.org/#/q/status:open+project:openstack/kuryr,n,z

Best regards,
Taku Fukushima
__
OpenStack Development Mailing 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] Errors in neutron-server while launching VM

2015-10-16 Thread Nasir Mahmood

Rahul,

You may need to re-create neutron DB...this error should never be seen in
your logs if your installation/configuration is gone good,

On Fri, Oct 16, 2015 at 3:22 PM, nithish B  wrote:

> Hi Rahul,
> Is the table "networks" available in the DB? Looks like it does not exist
> and thus when neutron queries the DB, it returns the error.
> Let me know.
>
> Thanks.
> Nitish B.
>
> Regards,
> Nitish B.
>
> On Fri, Oct 16, 2015 at 3:10 PM, Rahul Arora 
> wrote:
>
>> Hi Team.
>>
>> I am trying to run Openstack KILO release on my Ubuntu 14.04 x86
>> machine.I am able to run all the services.i.e glance,nova.keystone,neutron
>> etc successfully.
>>
>> But when i am trying to launch VM using below command manually.
>>
>> *nova boot --image 8f6e2973-c048-4445-8c31-38e159c930fc --flavor m1.tiny
>> "rahul"*
>>
>> I am getting below error in *neutron-server *service.
>> =
>>
>>
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
>> self.errorhandler(self, exc, value)
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource   File
>> "/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
>> defaulterrorhandler
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource raise
>> errorclass, errorvalue
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource OperationalError:
>> (OperationalError) (1054, "Unknown column 'networks.mtu' in 'field list'")
>> 'SELECT networks.tenant_id AS networks_tenant_id, networks.id AS
>> networks_id, networks.name AS networks_name, networks.status AS
>> networks_status, networks.admin_state_up AS networks_admin_state_up,
>> networks.shared AS networks_shared, networks.mtu AS networks_mtu,
>> networks.vlan_transparent AS networks_vlan_transparent,
>> ipallocationpools_1.id AS ipallocationpools_1_id,
>> ipallocationpools_1.subnet_id AS ipallocationpools_1_subnet_id,
>> ipallocationpools_1.first_ip AS ipallocationpools_1_first_ip,
>> ipallocationpools_1.last_ip AS ipallocationpools_1_last_ip,
>> dnsnameservers_1.address AS dnsnameservers_1_address,
>> dnsnameservers_1.subnet_id AS dnsnameservers_1_subnet_id,
>> subnetroutes_1.destination AS subnetroutes_1_destination,
>> subnetroutes_1.nexthop AS subnetroutes_1_nexthop, subnetroutes_1.subnet_id
>> AS subnetroutes_1_subnet_id, subnets_1.tenant_id AS subnets_1_tenant_id,
>> subnets_1.id AS subnets_1_id, subnets_1.name AS subnets_1_name,
>> subnets_1.network_id AS subnets_1_network_id, subnets_1.subnetpool_id AS
>> subnets_1_subnetpool_id, subnets_1.ip_version AS subnets_1_ip_version,
>> subnets_1.cidr AS subnets_1_cidr, subnets_1.gateway_ip AS
>> subnets_1_gateway_ip, subnets_1.enable_dhcp AS subnets_1_enable_dhcp,
>> subnets_1.shared AS subnets_1_shared, subnets_1.ipv6_ra_mode AS
>> subnets_1_ipv6_ra_mode, subnets_1.ipv6_address_mode AS
>> subnets_1_ipv6_address_mode, externalnetworks_1.network_id AS
>> externalnetworks_1_network_id \nFROM networks LEFT OUTER JOIN
>> externalnetworks ON networks.id = externalnetworks.network_id LEFT OUTER
>> JOIN subnets AS subnets_1 ON networks.id = subnets_1.network_id LEFT
>> OUTER JOIN ipallocationpools AS ipallocationpools_1 ON subnets_1.id =
>> ipallocationpools_1.subnet_id LEFT OUTER JOIN dnsnameservers AS
>> dnsnameservers_1 ON subnets_1.id = dnsnameservers_1.subnet_id LEFT OUTER
>> JOIN subnetroutes AS subnetroutes_1 ON subnets_1.id =
>> subnetroutes_1.subnet_id LEFT OUTER JOIN externalnetworks AS
>> externalnetworks_1 ON networks.id = externalnetworks_1.network_id
>> \nWHERE networks.tenant_id IN (%s) AND networks.shared IN (%s)'
>> ('75ee0e2b66e04287920904eb40351f57', 0)
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
>>
>> NOTE: I am using ml2 plugins to run  the neutron-server service.
>>
>> Please help me solving this issue.
>>
>> Thanks for the help.
>>
>>
>> --
>>
>> Regards
>>
>>
>> Rahul Arora
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openst...@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>


-- 
Nasir Mahmood
__
OpenStack Development Mailing 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] OpenStack versioning in Fuel

2015-10-16 Thread Igor Kalnitsky

Hey Oleg,

I've read the post [1] and I didn't get how exactly minor releases of
*stable* branch will be versioned?

Let's say 2015.2.0 is Liberty. How 2015.2.1 will be versioned?

[1] http://ttx.re/new-versioning.html

Thanks,
Igor


On Thu, Oct 15, 2015 at 6:59 PM, Oleg Gelbukh  wrote:
> Hello,
>
> I would like to highlight a problem that we are now going to have in Fuel
> regarding versioning of OpenStack.
>
> As you know, with introduction of the Big Tent policy it was decided that
> since Liberty dev cycle versioning schema of the whole project changes.
> Year-based versions won't be assigned to individual projects, nor the
> coordinated release is going to have unified number [1]. Individual projects
> will have semver version numbers, while numbering of the release itself
> seems to be dropped.
>
> However, in Fuel there is a lot of places where we use year-based version of
> OpenStack release. [2] How are we going to handle this? Shall we have
> openstack_version: 2015.2 all over the place? Or we should come up with
> something more sophisticated? Or just drop OpenStack version component from
> our versioning schema for good?
>
> Please, share your opinions here or in corresponding reviews.
>
> [1] http://ttx.re/new-versioning.html
> [2] https://review.openstack.org/#/c/234296/
>
> --
> Best regards,
> Oleg Gelbukh
>
> __
> OpenStack Development Mailing 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] OpenStack versioning in Fuel

2015-10-16 Thread Oleg Gelbukh

Igor,

The point is that there's no 2015.2.0 version anywhere in OpenStack. So
every component will be versioned separately, for example, in Libery, Nova
has version 12.0.0, and minor release of it is going to have version
12.0.1, while Keystone, for instance, will have version 11.0.0 and 11.0.1
for minor release.

The problem in Fuel is that coordinated release version is used in several
places, the most important being installation path of the fuel-library. We
won't be able to use it the same way since Liberty. I'd like to understand
how we are going to handle that.

My suggestion actually is to move away from using OpenStack version as a
part of Fuel version. Then the path to install the fuel-library will be
'/etc/puppet/8.0.0/'.

--
Best regards,
Oleg Gelbukh

On Fri, Oct 16, 2015 at 12:45 PM, Igor Kalnitsky 
wrote:

> Hey Oleg,
>
> I've read the post [1] and I didn't get how exactly minor releases of
> *stable* branch will be versioned?
>
> Let's say 2015.2.0 is Liberty. How 2015.2.1 will be versioned?
>
> [1] http://ttx.re/new-versioning.html
>
> Thanks,
> Igor
>
>
> On Thu, Oct 15, 2015 at 6:59 PM, Oleg Gelbukh 
> wrote:
> > Hello,
> >
> > I would like to highlight a problem that we are now going to have in Fuel
> > regarding versioning of OpenStack.
> >
> > As you know, with introduction of the Big Tent policy it was decided that
> > since Liberty dev cycle versioning schema of the whole project changes.
> > Year-based versions won't be assigned to individual projects, nor the
> > coordinated release is going to have unified number [1]. Individual
> projects
> > will have semver version numbers, while numbering of the release itself
> > seems to be dropped.
> >
> > However, in Fuel there is a lot of places where we use year-based
> version of
> > OpenStack release. [2] How are we going to handle this? Shall we have
> > openstack_version: 2015.2 all over the place? Or we should come up with
> > something more sophisticated? Or just drop OpenStack version component
> from
> > our versioning schema for good?
> >
> > Please, share your opinions here or in corresponding reviews.
> >
> > [1] http://ttx.re/new-versioning.html
> > [2] https://review.openstack.org/#/c/234296/
> >
> > --
> > Best regards,
> > Oleg Gelbukh
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [Tempest] where fwaas tempest tests should be?

2015-10-16 Thread Takashi Yamamoto

hi,

On Thu, Oct 15, 2015 at 11:17 PM, Matthew Treinish  wrote:
> On Thu, Oct 15, 2015 at 08:25:40PM +0900, Takashi Yamamoto wrote:
>> hi,
>>
>> i'm looking in fwaas tempest tests and have a question about code location.
>>
>> currently,
>>
>> - fwaas api tests and its rest client are in neutron repo
>
> This is a bad situation because it means that we're directly coupling fwaas to
> the neutron repo. Everything that depends on fwaas should be separate and self
> contained outside of the neutron repo. The longer that things are like this it
> will just lead to more headaches down the road.
>
>> - there are no fwaas scenario tests
>>
>> eventually,
>>
>> - fwaas api tests should be moved into neutron-fwaas repo
>> - fwaaa scenario tests should be in neutron-fwaas repo too.
>
> This is definitely the right direction.

if i move fwaas tests from neutron to neutron-fwaas, [1]
is there easy way to run them together with the rest of neutron api tests
for gate-neutron-dsvm-api job?

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

>
>> - the rest client will be in tempest-lib
>
> The discussion on which clients are in scope for tempest-lib hasn't fully
> happened yet. For right now we're taking a conservative approach and the 
> clients
> can live in tempest-lib if there are tests in the tempest tree using them.
> (which is not fwaas) This might change eventually, (there will be a summit
> session on it) but for right now I'd say the fwaas clients should live in the
> fwaas repo. (they can and likely should still be based on the tempest-lib rest
> client)
>
> -Matt 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

[openstack-dev] Error in neutron-server while launching VM

Hi Team.

I am trying to run Openstack KILO release on my Ubuntu 14.04 x86 machine.I
am able to run all the services.i.e glance,nova.keystone,neutron etc
successfully.

But when i am trying to launch VM using below command manually.

*nova boot --image 8f6e2973-c048-4445-8c31-38e159c930fc --flavor m1.tiny
"rahul"*

I am getting below error in *neutron-server *service.
=


2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
self.errorhandler(self, exc, value)
2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
defaulterrorhandler
2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource raise
errorclass, errorvalue
2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource OperationalError:
(OperationalError) (1054, "Unknown column 'networks.mtu' in 'field list'")
'SELECT networks.tenant_id AS networks_tenant_id, networks.id AS
networks_id, networks.name AS networks_name, networks.status AS
networks_status, networks.admin_state_up AS networks_admin_state_up,
networks.shared AS networks_shared, networks.mtu AS networks_mtu,
networks.vlan_transparent AS networks_vlan_transparent,
ipallocationpools_1.id AS ipallocationpools_1_id,
ipallocationpools_1.subnet_id AS ipallocationpools_1_subnet_id,
ipallocationpools_1.first_ip AS ipallocationpools_1_first_ip,
ipallocationpools_1.last_ip AS ipallocationpools_1_last_ip,
dnsnameservers_1.address AS dnsnameservers_1_address,
dnsnameservers_1.subnet_id AS dnsnameservers_1_subnet_id,
subnetroutes_1.destination AS subnetroutes_1_destination,
subnetroutes_1.nexthop AS subnetroutes_1_nexthop, subnetroutes_1.subnet_id
AS subnetroutes_1_subnet_id, subnets_1.tenant_id AS subnets_1_tenant_id,
subnets_1.id AS subnets_1_id, subnets_1.name AS subnets_1_name,
subnets_1.network_id AS subnets_1_network_id, subnets_1.subnetpool_id AS
subnets_1_subnetpool_id, subnets_1.ip_version AS subnets_1_ip_version,
subnets_1.cidr AS subnets_1_cidr, subnets_1.gateway_ip AS
subnets_1_gateway_ip, subnets_1.enable_dhcp AS subnets_1_enable_dhcp,
subnets_1.shared AS subnets_1_shared, subnets_1.ipv6_ra_mode AS
subnets_1_ipv6_ra_mode, subnets_1.ipv6_address_mode AS
subnets_1_ipv6_address_mode, externalnetworks_1.network_id AS
externalnetworks_1_network_id \nFROM networks LEFT OUTER JOIN
externalnetworks ON networks.id = externalnetworks.network_id LEFT OUTER
JOIN subnets AS subnets_1 ON networks.id = subnets_1.network_id LEFT OUTER
JOIN ipallocationpools AS ipallocationpools_1 ON subnets_1.id =
ipallocationpools_1.subnet_id LEFT OUTER JOIN dnsnameservers AS
dnsnameservers_1 ON subnets_1.id = dnsnameservers_1.subnet_id LEFT OUTER
JOIN subnetroutes AS subnetroutes_1 ON subnets_1.id =
subnetroutes_1.subnet_id LEFT OUTER JOIN externalnetworks AS
externalnetworks_1 ON networks.id = externalnetworks_1.network_id \nWHERE
networks.tenant_id IN (%s) AND networks.shared IN (%s)'
('75ee0e2b66e04287920904eb40351f57', 0)
2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource

NOTE: I am using ml2 plugins to run  the neutron-server service.

Please help me solving this issue.

Thanks for the help.
__
OpenStack Development Mailing 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]What happened when the 3-rd controller restarted?

2015-10-16 Thread Germy Lure

Hi Salvatore,

Thanks so much for your continuing answers. What you mentioned is partially
where I was going. Indeed, I want to solve the whole consistency issue, not
just at startup. I just thought that ensuring consistency at startup and
each operation is enough for it. A periodic task need more resource.

OK, anyway, I would think about filing a bug or BP to push this moving
forward.
Thanks for the help. Will get back to you if required.

Germy
.



On Fri, Oct 16, 2015 at 1:46 AM, Salvatore Orlando 
wrote:

> Hi Germy,
>
> It seems that you're looking at solutions for ensuring consistency between
> the "desired" configuration (Neutron), and the actual one (whatever is in
> your backend) at startup.
> This has been discussed several times in the past - not just for
> synchronization at startup, but also for ensuring neutron and the backend
> are in sync at each operation.
>
> At a very high level I think a "general" solution is only partially
> possible. At some point there must be a plugin interface that verifies
> whether, for a given resource, data on the backend differ from those in
> neutron.
> The component which evaluates the result of such operation and updates the
> status of the resources being synchronised could instead be shared across
> plugins.
> For the ML2 plugin I don't see any architectural difference, beyond the
> fact that the plugin level operation should probably query all the
> mechanism drivers.
>
> Anyway, If this is something you'd like to see implemented (regardless of
> whether my analysis matches your use case) you should considering filing a
> RFE bug so that it will be considered during the drivers meetings.
>
> Salvatore
>
> On 14 October 2015 at 11:43, Germy Lure  wrote:
>
>> Hi Salvatore and Kevin,
>>
>> I'm sorry for replying so late.
>> I wanted to see whether the community had considered data sync for these
>> two style(agent and controller) integration. To solve integrating multiple
>> vendor's controllers, I need some help from community. That's the original
>> purpose of this thread. In another word, I had no idea when I sent this
>> message and I just asked some help.
>>
>> Anyway, the issues I mentioned last mail are exists. We still need face
>> them. I have some rough ideas for your reference.
>>
>> 1.try best to keep the source is correct.
>> Think about CREATE operation, if the backend was be in exception and
>> Neutron is timeout, then the record should be destroyed or marked ERROR to
>> warn the operator. If Neutron was be in exception, the backend will has an
>> extra record. To avoid this, Neutron could store and mark a record
>> CREATE_PENDING before push it to backend, then scan data and check with the
>> backend after restarting when exception occurs. If the record in Neutron is
>> extra, destroy or mark ERROR to warn the operator. UPDATE and DELETE need
>> similar logic.
>> Currently in Neutron, some objects have defined XX_PENDING and some not.
>> 2.check each other when they restart.
>> After restarting, the backend should report the states of all objects and
>> may re-load data from Neutron to rebuild or check local data. When Neutron
>> restarting, it should get data from backend and check it. Maybe, it can
>> notify backend, and backend act as it just restarted.
>> All in all, I think it's enough that keeping the data be correct when you
>> write(CUD) it and check it when restarting.
>>
>> About implementation, I think a common frame is best. Plugins or even
>> drivers just provide methods for backend to load data, update state and
>> etc.
>>
>> As I mentioned earlier, this is just a rough and superficial idea. Any
>> comment please.
>>
>> Thanks,
>> Germy
>> .
>>
>>
>>
>> On Tue, Oct 13, 2015 at 3:28 AM, Kevin Benton  wrote:
>>
>>> >*But there is no such a feature in Neutron. Right? Will the community
>>> merge it soon? And can we consider it with agent-style mechanism together?*
>>>
>>> The agents have their own mechanisms for getting information from the
>>> server. The community has no plans to merge a feature that is going to be
>>> different for almost every vendor.
>>>
>>> We tried to come up with some common syncing stuff in the recent ML2
>>> meeting, the various backends had different methods of detecting when they
>>> were out of sync with Neutron (e.g. headers in hashes, recording errors,
>>> etc), all of which depended on the capabilities of the backend. Then the
>>> sync method itself was different between backends (sending deltas, sending
>>> entire state, sending a replay log, etc).
>>>
>>> About the only thing they have in common is that they need a way detect
>>> if they are out of sync and they need a method to sync. So that's two
>>> abstract methods, and we likely can't even agree on when they should be
>>> called.
>>>
>>> Echoing Salvatore's comments, what is it that you want to see?
>>>
>>> On Mon, Oct 12, 2015 at 12:29 AM, Germy Lure

[openstack-dev] [neutron]How to install lbaas integrating with barbican?

2015-10-16 Thread Germy Lure

Hi stackers,

I plan to test the https functionality of lbaas. Can anyone paste some
guide hyperlink about installation, deployment and operation?

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

[openstack-dev] [cinder] Is there any cli command for "manage_existing"?

2015-10-16 Thread liuxinguo

Hi,
I have saw the "manage_existing" interface in cinder/contrib/volume_manager.py 
but can't find the responding cli command.
Is there any cli command for "manage_existing"? If not, who will call this api?

Thanks for any input!
Wilson Liu
__
OpenStack Development Mailing 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] Errors in neutron-server while launching VM

2015-10-16 Thread nithish B

Hi Rahul,
Is the table "networks" available in the DB? Looks like it does not exist
and thus when neutron queries the DB, it returns the error.
Let me know.

Thanks.
Nitish B.

Regards,
Nitish B.

On Fri, Oct 16, 2015 at 3:10 PM, Rahul Arora 
wrote:

> Hi Team.
>
> I am trying to run Openstack KILO release on my Ubuntu 14.04 x86 machine.I
> am able to run all the services.i.e glance,nova.keystone,neutron etc
> successfully.
>
> But when i am trying to launch VM using below command manually.
>
> *nova boot --image 8f6e2973-c048-4445-8c31-38e159c930fc --flavor m1.tiny
> "rahul"*
>
> I am getting below error in *neutron-server *service.
> =
>
>
> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
> self.errorhandler(self, exc, value)
> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource   File
> "/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
> defaulterrorhandler
> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource raise
> errorclass, errorvalue
> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource OperationalError:
> (OperationalError) (1054, "Unknown column 'networks.mtu' in 'field list'")
> 'SELECT networks.tenant_id AS networks_tenant_id, networks.id AS
> networks_id, networks.name AS networks_name, networks.status AS
> networks_status, networks.admin_state_up AS networks_admin_state_up,
> networks.shared AS networks_shared, networks.mtu AS networks_mtu,
> networks.vlan_transparent AS networks_vlan_transparent,
> ipallocationpools_1.id AS ipallocationpools_1_id,
> ipallocationpools_1.subnet_id AS ipallocationpools_1_subnet_id,
> ipallocationpools_1.first_ip AS ipallocationpools_1_first_ip,
> ipallocationpools_1.last_ip AS ipallocationpools_1_last_ip,
> dnsnameservers_1.address AS dnsnameservers_1_address,
> dnsnameservers_1.subnet_id AS dnsnameservers_1_subnet_id,
> subnetroutes_1.destination AS subnetroutes_1_destination,
> subnetroutes_1.nexthop AS subnetroutes_1_nexthop, subnetroutes_1.subnet_id
> AS subnetroutes_1_subnet_id, subnets_1.tenant_id AS subnets_1_tenant_id,
> subnets_1.id AS subnets_1_id, subnets_1.name AS subnets_1_name,
> subnets_1.network_id AS subnets_1_network_id, subnets_1.subnetpool_id AS
> subnets_1_subnetpool_id, subnets_1.ip_version AS subnets_1_ip_version,
> subnets_1.cidr AS subnets_1_cidr, subnets_1.gateway_ip AS
> subnets_1_gateway_ip, subnets_1.enable_dhcp AS subnets_1_enable_dhcp,
> subnets_1.shared AS subnets_1_shared, subnets_1.ipv6_ra_mode AS
> subnets_1_ipv6_ra_mode, subnets_1.ipv6_address_mode AS
> subnets_1_ipv6_address_mode, externalnetworks_1.network_id AS
> externalnetworks_1_network_id \nFROM networks LEFT OUTER JOIN
> externalnetworks ON networks.id = externalnetworks.network_id LEFT OUTER
> JOIN subnets AS subnets_1 ON networks.id = subnets_1.network_id LEFT
> OUTER JOIN ipallocationpools AS ipallocationpools_1 ON subnets_1.id =
> ipallocationpools_1.subnet_id LEFT OUTER JOIN dnsnameservers AS
> dnsnameservers_1 ON subnets_1.id = dnsnameservers_1.subnet_id LEFT OUTER
> JOIN subnetroutes AS subnetroutes_1 ON subnets_1.id =
> subnetroutes_1.subnet_id LEFT OUTER JOIN externalnetworks AS
> externalnetworks_1 ON networks.id = externalnetworks_1.network_id \nWHERE
> networks.tenant_id IN (%s) AND networks.shared IN (%s)'
> ('75ee0e2b66e04287920904eb40351f57', 0)
> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
>
> NOTE: I am using ml2 plugins to run  the neutron-server service.
>
> Please help me solving this issue.
>
> Thanks for the help.
>
>
> --
>
> Regards
>
>
> Rahul Arora
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Is there any cli command for "manage_existing"?

2015-10-16 Thread Ivan Kolodyazhny

Hi,

There is "cinder manage" command [1] in the python-cinderclient.

[1]
https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/shell.py#L2063

Regards,
Ivan Kolodyazhny

On Fri, Oct 16, 2015 at 1:06 PM, liuxinguo  wrote:

> Hi,
>
> I have saw the “manage_existing” interface in
> cinder/contrib/volume_manager.py but can’t find the responding cli command.
>
> Is there any cli command for “manage_existing”? If not, who will call this
> api?
>
>
>
> Thanks for any input!
>
> Wilson Liu
>
> __
> OpenStack Development Mailing 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] Errors in neutron-server while launching VM

Hi Team.

I am trying to run Openstack KILO release on my Ubuntu 14.04 x86 machine.I
am able to run all the services.i.e glance,nova.keystone,neutron etc
successfully.

But when i am trying to launch VM using below command manually.

*nova boot --image 8f6e2973-c048-4445-8c31-38e159c930fc --flavor m1.tiny
"rahul"*

I am getting below error in *neutron-server *service.
=


2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
self.errorhandler(self, exc, value)
2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
defaulterrorhandler
2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource raise
errorclass, errorvalue
2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource OperationalError:
(OperationalError) (1054, "Unknown column 'networks.mtu' in 'field list'")
'SELECT networks.tenant_id AS networks_tenant_id, networks.id AS
networks_id, networks.name AS networks_name, networks.status AS
networks_status, networks.admin_state_up AS networks_admin_state_up,
networks.shared AS networks_shared, networks.mtu AS networks_mtu,
networks.vlan_transparent AS networks_vlan_transparent,
ipallocationpools_1.id AS ipallocationpools_1_id,
ipallocationpools_1.subnet_id AS ipallocationpools_1_subnet_id,
ipallocationpools_1.first_ip AS ipallocationpools_1_first_ip,
ipallocationpools_1.last_ip AS ipallocationpools_1_last_ip,
dnsnameservers_1.address AS dnsnameservers_1_address,
dnsnameservers_1.subnet_id AS dnsnameservers_1_subnet_id,
subnetroutes_1.destination AS subnetroutes_1_destination,
subnetroutes_1.nexthop AS subnetroutes_1_nexthop, subnetroutes_1.subnet_id
AS subnetroutes_1_subnet_id, subnets_1.tenant_id AS subnets_1_tenant_id,
subnets_1.id AS subnets_1_id, subnets_1.name AS subnets_1_name,
subnets_1.network_id AS subnets_1_network_id, subnets_1.subnetpool_id AS
subnets_1_subnetpool_id, subnets_1.ip_version AS subnets_1_ip_version,
subnets_1.cidr AS subnets_1_cidr, subnets_1.gateway_ip AS
subnets_1_gateway_ip, subnets_1.enable_dhcp AS subnets_1_enable_dhcp,
subnets_1.shared AS subnets_1_shared, subnets_1.ipv6_ra_mode AS
subnets_1_ipv6_ra_mode, subnets_1.ipv6_address_mode AS
subnets_1_ipv6_address_mode, externalnetworks_1.network_id AS
externalnetworks_1_network_id \nFROM networks LEFT OUTER JOIN
externalnetworks ON networks.id = externalnetworks.network_id LEFT OUTER
JOIN subnets AS subnets_1 ON networks.id = subnets_1.network_id LEFT OUTER
JOIN ipallocationpools AS ipallocationpools_1 ON subnets_1.id =
ipallocationpools_1.subnet_id LEFT OUTER JOIN dnsnameservers AS
dnsnameservers_1 ON subnets_1.id = dnsnameservers_1.subnet_id LEFT OUTER
JOIN subnetroutes AS subnetroutes_1 ON subnets_1.id =
subnetroutes_1.subnet_id LEFT OUTER JOIN externalnetworks AS
externalnetworks_1 ON networks.id = externalnetworks_1.network_id \nWHERE
networks.tenant_id IN (%s) AND networks.shared IN (%s)'
('75ee0e2b66e04287920904eb40351f57', 0)
2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource

NOTE: I am using ml2 plugins to run  the neutron-server service.

Please help me solving this issue.

Thanks for the help.


--

Regards


Rahul Arora
__
OpenStack Development Mailing 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]How to install lbaas integrating with barbican?

2015-10-16 Thread santosh sharma

Hope this helps:
https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer

Thanks
Santosh
art.chitrprayatan.co.in

On Fri, Oct 16, 2015 at 3:25 PM, Germy Lure  wrote:

> Hi stackers,
>
> I plan to test the https functionality of lbaas. Can anyone paste some
> guide hyperlink about installation, deployment and operation?
>
> Thank you.
> Germy
> .
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [oslo] Require documenting changes with versionadded and versionchanged

2015-10-16 Thread Victor Stinner

Le 15/10/2015 17:54, Joshua Harlow a écrit :

I had this problem with deprecation versioning (the debtcollector
library functions take a version="XYZ", removal_version="ABC" params,
see
http://docs.openstack.org/developer/debtcollector/examples.html#further-customizing-the-emitted-messages)
and it is pretty hard to get those two numbers right, especially with
weekly releases and not knowing when a review will merge... I'm not
saying we shouldn't try to do this, but we just have to figure out how
to do it in a smart way.

I hope that we will not release *too* frequently. Oslo libraries are
supposed to be somehow "stable" :-) Past history showed that any minor
change has major impact on the OpenStack CI ;-)

If we have to choose between "documenting changes with the wrong version
number" and "don't document changes", I pick the wrong version. IHMO
it's better than doc at all.

As I replied to Brant, I don't expect so much issues between doc and
version numbers.

In a few weeks, if we consider that we have too many issues between doc
and versions, it would maybe be time to rethink how we release Oslo
libraries? Maybe our release process should be enhanced to review more
carefully changes before a release?

By the way, Sphinx has a great tool to extract *all* versionchanged and
versionadded. It's super useful to prepare a change log for humans. But
it can also help to check the documentation of changes before a release,
maybe manual check at the beginning?

The most basic check is to compute the diff since the previous release
and check manually all versionadded and versionchanged.

Perhaps there need to be a gerrit based way to add these, so for example
a review submitter would write:

".. versionadded:: $FILL_ME_IN_WHEN_MERGED" and ".. versionchanged::
$FILL_ME_IN_WHEN_MERGED" or something, and gerrit when merging code
would change those into real numbers...

Hey, it remembers me CVS :-D It may work, but such tool has to be
written first ;-) It may also make the release process more complex.
Right now, it's quite simple: pick any Git SHA1 and this hash becomes
your release. No *any* change between this revision and the final release.

Victor

__
OpenStack Development Mailing 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] [QA] Design Summit Schedule

2015-10-16 Thread Dmitry Tantsur


On 10/15/2015 06:42 PM, Matthew Treinish wrote:


Hi Everyone,

I just pushed up the QA schedule for design summit:

https://mitakadesignsummit.sched.org/overview/type/qa

Let me know if there are any big schedule conflicts or other issues, so we can
work through the problem.


Hi!

I wonder if it's possible to move "QA: Tempest Microversion Support and 
Testing" one slot down (to 3:40), so that Ironic people can attend.




Thanks,

Matt 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

[openstack-dev] [neutron][calico] networking-calico 1.0.0

I'm happy to announce the first release of networking-calico.  As it
says at http://docs.openstack.org/developer/networking-calico/:

  networking-calico is the Neutron ‘stadium’ sub-project that provides
  ‘Calico’ connectivity and security in an OpenStack/Neutron cloud.

  Calico [1] uses IP routing to provide connectivity between the
  workloads in a data center that provide or use IP-based services -
  whether VMs, containers or bare metal appliances; and iptables, to
  impose any desired fine-grained security policy between those
  workloads. Calico thus differs from most other Neutron backends,
  which use bridging and tunneling to simulate L2-level connectivity
  between the VMs attached to a Neutron network.

  [1] http://www.projectcalico.org

Release notes, as at
https://launchpad.net/networking-calico/+milestone/1.0.0:

  First release of networking-calico.

  - Calico integration with vanilla Liberty OpenStack (i.e. without
requiring any Calico-specific patching).

  - DevStack plugin that makes it easy to set up and use a single or
multi-node Calico/DevStack cluster.

  For documentation, please see:

  - http://docs.openstack.org/developer/networking-calico/, for
networking-calico as a whole

  - http://docs.openstack.org/developer/networking-calico/devstack.html,
for how to use the DevStack plugin.

Please do let me know of any feedback.  In the coming weeks I will aim
to establish a regular IRC meeting for this project, so as to widen
participation; so it would be good to know who would be interested in that.

Many thanks,
Neil


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

Re: [openstack-dev] [Openstack] Errors in neutron-server while launching VM

Hi Nitish,

When i am trying to see table "networks" in the DB.I am not able to use
"show tables" command to see tables.looks like it this version does not
suppor that.

List of all MySQL commands:
Note that all text commands must be first on line and end with ';'
? (\?) Synonym for `help'.
clear (\c) Clear the current input statement.
connect   (\r) Reconnect to the server. Optional arguments are db and host.
delimiter (\d) Set statement delimiter.
edit  (\e) Edit command with $EDITOR.
ego   (\G) Send command to mysql server, display result vertically.
exit  (\q) Exit mysql. Same as quit.
go(\g) Send command to mysql server.
help  (\h) Display this help.
nopager   (\n) Disable pager, print to stdout.
notee (\t) Don't write into outfile.
pager (\P) Set PAGER [to_pager]. Print the query results via PAGER.
print (\p) Print current command.
prompt(\R) Change your mysql prompt.
quit  (\q) Quit mysql.
rehash(\#) Rebuild completion hash.
source(\.) Execute an SQL script file. Takes a file name as an argument.
status(\s) Get status information from the server.
system(\!) Execute a system shell command.
tee   (\T) Set outfile [to_outfile]. Append everything into given
outfile.
use   (\u) Use another database. Takes database name as argument.
charset   (\C) Switch to another charset. Might be needed for processing
binlog with multi-byte charsets.
warnings  (\W) Show warnings after every statement.
nowarning (\w) Don't show warnings after every statement.

For server side help, type 'help contents'

mysql>

Can you please redirect me how i can see this?

--

Regards

Rahul Arora

On Fri, Oct 16, 2015 at 3:52 PM, nithish B  wrote:

> Hi Rahul,
> Is the table "networks" available in the DB? Looks like it does not exist
> and thus when neutron queries the DB, it returns the error.
> Let me know.
>
> Thanks.
> Nitish B.
>
> Regards,
> Nitish B.
>
> On Fri, Oct 16, 2015 at 3:10 PM, Rahul Arora 
> wrote:
>
>> Hi Team.
>>
>> I am trying to run Openstack KILO release on my Ubuntu 14.04 x86
>> machine.I am able to run all the services.i.e glance,nova.keystone,neutron
>> etc successfully.
>>
>> But when i am trying to launch VM using below command manually.
>>
>> *nova boot --image 8f6e2973-c048-4445-8c31-38e159c930fc --flavor m1.tiny
>> "rahul"*
>>
>> I am getting below error in *neutron-server *service.
>> =
>>
>>
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
>> self.errorhandler(self, exc, value)
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource   File
>> "/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
>> defaulterrorhandler
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource raise
>> errorclass, errorvalue
>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource OperationalError:
>> (OperationalError) (1054, "Unknown column 'networks.mtu' in 'field list'")
>> 'SELECT networks.tenant_id AS networks_tenant_id, networks.id AS
>> networks_id, networks.name AS networks_name, networks.status AS
>> networks_status, networks.admin_state_up AS networks_admin_state_up,
>> networks.shared AS networks_shared, networks.mtu AS networks_mtu,
>> networks.vlan_transparent AS networks_vlan_transparent,
>> ipallocationpools_1.id AS ipallocationpools_1_id,
>> ipallocationpools_1.subnet_id AS ipallocationpools_1_subnet_id,
>> ipallocationpools_1.first_ip AS ipallocationpools_1_first_ip,
>> ipallocationpools_1.last_ip AS ipallocationpools_1_last_ip,
>> dnsnameservers_1.address AS dnsnameservers_1_address,
>> dnsnameservers_1.subnet_id AS dnsnameservers_1_subnet_id,
>> subnetroutes_1.destination AS subnetroutes_1_destination,
>> subnetroutes_1.nexthop AS subnetroutes_1_nexthop, subnetroutes_1.subnet_id
>> AS subnetroutes_1_subnet_id, subnets_1.tenant_id AS subnets_1_tenant_id,
>> subnets_1.id AS subnets_1_id, subnets_1.name AS subnets_1_name,
>> subnets_1.network_id AS subnets_1_network_id, subnets_1.subnetpool_id AS
>> subnets_1_subnetpool_id, subnets_1.ip_version AS subnets_1_ip_version,
>> subnets_1.cidr AS subnets_1_cidr, subnets_1.gateway_ip AS
>> subnets_1_gateway_ip, subnets_1.enable_dhcp AS subnets_1_enable_dhcp,
>> subnets_1.shared AS subnets_1_shared, subnets_1.ipv6_ra_mode AS
>> subnets_1_ipv6_ra_mode, subnets_1.ipv6_address_mode AS
>> subnets_1_ipv6_address_mode, externalnetworks_1.network_id AS
>> externalnetworks_1_network_id \nFROM networks LEFT OUTER JOIN
>> externalnetworks ON networks.id = externalnetworks.network_id LEFT OUTER
>> JOIN subnets AS subnets_1 ON networks.id = subnets_1.network_id LEFT
>> OUTER JOIN ipallocationpools AS ipallocationpools_1 ON subnets_1.id =
>> ipallocationpools_1.subnet_id LEFT OUTER JOIN dnsnameservers AS
>> dnsnameservers_1 ON subnets_1.id = dnsnameservers_1.subnet_id LEFT OUTER
>> JOIN subnetroutes AS subnetroutes_1 ON subnets_1.id =
>>

Re: [openstack-dev] [Fuel] Proposal to freeze old Fuel CLI

2015-10-16 Thread Igor Kalnitsky

+1 to Sebastian.

On Wed, Oct 14, 2015 at 12:13 PM, Sebastian Kalinowski
 wrote:
> Roman, this was already discussed in [1].
> The conclusion was that we will implement new features in both places so
> user will not have to
> use "old" fuelclient to do some things and the "new" to others.
> There were no progress with moving old commands to new CLI and I didn't seen
> plans to do so.
> IMHO without a detailed plan on migrating old commands to new client and
> without a person (or people)
> that will drive this task we *cannot* freeze old fuelclient as new one is
> still not fully usable.
>
> Best,
> Sebastian
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070279.html
>
>
> 2015-10-14 10:56 GMT+02:00 Roman Prykhodchenko :
>>
>> Fuelers,
>>
>> as you know a big effort has been put into making Fuel Client’s CLI better
>> and as a result we got a new fuel2 utility with a new set of commands and
>> options. Some folks still put great effort to move everything that’s left in
>> the old CLI to the new CLI.
>>
>> Every new thing added to the old CLI moves the point where we can finally
>> remove it to the future. My proposal is to do a hard code freeze for the old
>> CLI and only add new stuff to the new one.
>>
>>
>> - romcheg
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing 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] [ceilometer][aodh] proposal to add Ryota Mibu to Aodh core

2015-10-16 Thread gord chung


hi,

i'd like to nominate Ryota Mibu to the Aodh core team. he has been an 
active participant in Aodh and leads the Event alarms work done there. 
he also brings good insight related to NFV use case.


patches:
https://review.openstack.org/#/q/owner:%22Ryota+MIBU%22+project:openstack/aodh,n,z

reviews:
https://review.openstack.org/#/q/reviewer:%22Ryota+MIBU%22+project:openstack/aodh,n,z

cheers,

--
gord


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

Re: [openstack-dev] Make libguestfs available on pypi

2015-10-16 Thread Matt Thompson

Hi All,

Does anyone know if any progress has been made here?  We're doing something
similar to Kris and it'd be great if libguestfs could be installed directly
from pypi.

Any information is appreciated.

Thanks!

--Matt



On Thu, Jul 30, 2015 at 12:38 PM, Richard W.M. Jones 
wrote:

> On Thu, Jul 30, 2015 at 11:14:20AM +1000, Ian Wienand wrote:
> > On 07/30/2015 04:55 AM, Kris G. Lindgren wrote:
> > > The following bug has already been created over a year ago [1], and
> > > it looks like most of the work on the libguestfs side is already
> > > done [2].  It seems something about a complaint of licensing per
> > > the bug report.
> >
> > I think best to follow up in that bug
> >
> > On the license front, to quote from an internal email I
> > saw fly-by about the pypi sign-up terms under question from Nick on
> > 20-Jul-2015:
> >
> > ---
> >  Van started drafting some amendments back in February:
> >  https://bitbucket.org/vanl/pypi/commits/all
> >
> >  Key changes are here:
> >
> https://bitbucket.org/vanl/pypi/commits/8df8e0295c0a719e963f7c3ce430284179f03b1f
> >
> >  Further clarifications at
> >
> https://bitbucket.org/vanl/pypi/commits/734b1f49776d1f7f5d0671306f61a90aad713e5d
> >  and
> >
> https://bitbucket.org/vanl/pypi/commits/0e94b169e81306607936912ecc3c42312aac5eb7
> >
> >  I'll ping the Board list about next steps in getting those amendments
> >  formally approved and submitted as a PR to the main PyPI repo.
> > ---
> >
> > So it is being looked at, but I'm not sure of the time-frame.
>
> Yup, you beat me to it.  Earlier this month I asked the Python
> Software Foundation to look again at their terms, and they have agreed
> to make some changes.  It's my understanding that it is waiting on the
> PSF Board to approve changes.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
>
> __
> OpenStack Development Mailing 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] OpenStack versioning in Fuel

2015-10-16 Thread Igor Kalnitsky

Oleg,

Yes, I know. Still you didn't answer my question - are they planning
to release stable branches time-to-time? Like I said, Liberty is
something similar 2015.2.0. How they will name release of something
like 2015.2.1 (stable release, with bugfixes) ? Or they plan to drop
it?

Thanks,
Igor

On Fri, Oct 16, 2015 at 1:02 PM, Oleg Gelbukh  wrote:
> Igor,
>
> The point is that there's no 2015.2.0 version anywhere in OpenStack. So
> every component will be versioned separately, for example, in Libery, Nova
> has version 12.0.0, and minor release of it is going to have version 12.0.1,
> while Keystone, for instance, will have version 11.0.0 and 11.0.1 for minor
> release.
>
> The problem in Fuel is that coordinated release version is used in several
> places, the most important being installation path of the fuel-library. We
> won't be able to use it the same way since Liberty. I'd like to understand
> how we are going to handle that.
>
> My suggestion actually is to move away from using OpenStack version as a
> part of Fuel version. Then the path to install the fuel-library will be
> '/etc/puppet/8.0.0/'.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Fri, Oct 16, 2015 at 12:45 PM, Igor Kalnitsky 
> wrote:
>>
>> Hey Oleg,
>>
>> I've read the post [1] and I didn't get how exactly minor releases of
>> *stable* branch will be versioned?
>>
>> Let's say 2015.2.0 is Liberty. How 2015.2.1 will be versioned?
>>
>> [1] http://ttx.re/new-versioning.html
>>
>> Thanks,
>> Igor
>>
>>
>> On Thu, Oct 15, 2015 at 6:59 PM, Oleg Gelbukh 
>> wrote:
>> > Hello,
>> >
>> > I would like to highlight a problem that we are now going to have in
>> > Fuel
>> > regarding versioning of OpenStack.
>> >
>> > As you know, with introduction of the Big Tent policy it was decided
>> > that
>> > since Liberty dev cycle versioning schema of the whole project changes.
>> > Year-based versions won't be assigned to individual projects, nor the
>> > coordinated release is going to have unified number [1]. Individual
>> > projects
>> > will have semver version numbers, while numbering of the release itself
>> > seems to be dropped.
>> >
>> > However, in Fuel there is a lot of places where we use year-based
>> > version of
>> > OpenStack release. [2] How are we going to handle this? Shall we have
>> > openstack_version: 2015.2 all over the place? Or we should come up with
>> > something more sophisticated? Or just drop OpenStack version component
>> > from
>> > our versioning schema for good?
>> >
>> > Please, share your opinions here or in corresponding reviews.
>> >
>> > [1] http://ttx.re/new-versioning.html
>> > [2] https://review.openstack.org/#/c/234296/
>> >
>> > --
>> > Best regards,
>> > Oleg Gelbukh
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

2015-10-16 Thread Christian Berendt

On 10/16/2015 01:46 PM, Neil Jerram wrote:
> I'd be happy to submit a fix for this, but I haven't yet found which
> project generates this URL.  Can someone advise?

The developer documentations use the oslosphinx
theme.(http://git.openstack.org/cgit/openstack/oslosphinx). The
mentioned URL is generated in
https://github.com/openstack/oslosphinx/blob/master/oslosphinx/__init__.py#L20-L36.
Probably there is something wrong.

Christian.

-- 
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

__
OpenStack Development Mailing 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] [ceilometer][aodh] proposal to add Ryota Mibu to Aodh core

2015-10-16 Thread gord chung

sorry, as we usually do, please comment on gerrit[1]. if you cannot, 
then please comment here.


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

On 16/10/15 08:39 AM, gord chung wrote:

hi,

i'd like to nominate Ryota Mibu to the Aodh core team. he has been an 
active participant in Aodh and leads the Event alarms work done there. 
he also brings good insight related to NFV use case.


patches:
https://review.openstack.org/#/q/owner:%22Ryota+MIBU%22+project:openstack/aodh,n,z 



reviews:
https://review.openstack.org/#/q/reviewer:%22Ryota+MIBU%22+project:openstack/aodh,n,z 



cheers,



--
gord


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

[openstack-dev] [stable/liberty] [requirements]/[oslo] ceilometer jobs failing.

2015-10-16 Thread Tony Breeds

Hi All,
We have an issue for any review that causes a new commit to ceilometer, it
will fail with[1]:

ValueError: git history requires a target version of
pbr.version.SemanticVersion(5.0.1), but target version is
pbr.version.SemanticVersion(5.0.0)

Switching to post-versioning[2] can't land because of [3]  The fix for that is
to ban 2.6.1 (and 2.6.0) from requirements.  That can't land because of[1],
and we've come full circle.

I can't use Depends-On as the patches in each repo need to land at the same
time.  So I tried the "obvious squash" patch at [4], but that isn't going to
work because of the sensible requirements checking.

The only way it fix this I can think of is to release 2.6.2 of oslo.messaging
with the fixes needed by ceilometer (which have merged).

I can think of a couple of rather terrible ways to hack around this but lets
not go there unless there is a good reason to not release 2.6.2

Yours Tony.

[1] https://bugs.launchpad.net/ceilometer/+bug/1506805
[2] https://review.openstack.org/#/c/235207/
[3] https://bugs.launchpad.net/oslo.messaging/+bug/1505730
[4] https://review.openstack.org/#/c/235815/
[5] https://review.openstack.org/#/c/235536/


pgpK5e0UUHwYT.pgp
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] logstash URL queries.

2015-10-16 Thread Tony Breeds

Hi Everybody,
So it looks to me like we recently updated logstash.openstack.org to a
newer version of kibabna?

I'll very openly admit that my logstash fu is wanting but I'm having a little
trouble

1) I can't work out how to after performing my query/filtering share the
   results (for example in a LP bug).  I tried using the sharable link but it
   always comes up with:
   http://logstash.openstack.org/#dashboard/undefined/undefined
   and that URL doesn't work by magic :(

   How do we share queries now?

2) It looks to me like all our old saved URLs are now invalid, this is a big of
   a problem for open bugs with logstash URLs in them.

   Is there anyway we can make the old URLs work again?

3) I'm sure that the following is a valid query:
   message:"ValueError: git history requires a target version of 
pbr.version.SemanticVersion(5.0.1), but target version is 
pbr.version.SemanticVersion(5.0.0)" AND tags:"console" AND 
project:openstack/requirements
   but it just spins and never seems to return any matches.  If instead I set
   the query to :
   message:"ValueError: git history requires a target version of 
pbr.version.SemanticVersion(5.0.1), but target version is 
pbr.version.SemanticVersion(5.0.0)"
   and use the UI to add filters for tags:"console" and 
project:openstack/requirements

   I do get some results.

   Is there a problem with my query or the backend?

Just to be clear, I don't mean this email to sound like I'm complaining, I'm
just confused and looking for help.


Yours Tony.


pgpLxOOJJB36L.pgp
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] [packaging] liberty doesn't have caps on deps

Excerpts from Robert Collins's message of 2015-10-16 09:29:21 +1300:
> On 16 October 2015 at 08:57, Doug Hellmann  wrote:
> > Excerpts from Matthew Thode's message of 2015-10-15 14:35:08 -0500:
> >> On 10/15/2015 02:17 PM, Matt Riedemann wrote:
> >> >
> 
> >
> > We're going to try to cover it in
> > http://mitakadesignsummit.sched.org/event/27c17a3c35d72997b372ddf4759fe1be#.ViAE67SO820
> > but we have a lot of other things to fit into that session so I want to
> > put this one last so we don't derail the other discussions.
> 
> I thought it was
> http://mitakadesignsummit.sched.org/event/0a2307779b4ab81892ba24de379e9dcc#.ViAMfd94u00
> that it was slated for, where its squarely on topic :)
> 
> -Rob
> 

It may fit there, too, but I don't know if Sean expects the existing
outline to fill the time slot.

Doug

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

Re: [openstack-dev] Make libguestfs available on pypi

2015-10-16 Thread Richard W.M. Jones

On Fri, Oct 16, 2015 at 12:58:20PM +0100, Matt Thompson wrote:
> Hi All,
> 
> Does anyone know if any progress has been made here?  We're doing something
> similar to Kris and it'd be great if libguestfs could be installed directly
> from pypi.

Good and bad news.  No movement on the PyPi sign-up / licensing issue
as far as I'm aware, so I'm still unable to agree to uploading the
Python bindings to PyPi.  [I tried to sign up again just now, but the
email is taking a very long time to come through - will update here if
there is any change]

However the good news is I fixed libguestfs so that you can now build
the Python bindings separate from the C library.  See this commit for
details:

https://github.com/libguestfs/libguestfs/commit/bb7d088edaa2ea3a664ae703e002f6297dd1844f

That commit was also backported to 1.30.3 on the stable-1.30 branch.

For instructions on how to actually build a PIP module, see:

https://github.com/libguestfs/libguestfs/commit/fcbfc4775fa2a44020974073594a745ca420d614

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

__
OpenStack Development Mailing 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][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

If you go to
http://docs.openstack.org/developer/openstack-projects.html, then go
from there into any project page, the 'Project Source' URL in the
sidebar is wrong.

(Well, I say 'any', but I've only actually tried for ironic,
networking-midonet and networking-calico.  Those all show the following
problem.)

For example, at http://docs.openstack.org/developer/ironic/ the URL is
http://git.openstack.org/cgit/p/openstack/ironic, but it should be
http://git.openstack.org/cgit/openstack/ironic.

I'd be happy to submit a fix for this, but I haven't yet found which
project generates this URL.  Can someone advise?

Regards,
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-dev] [Third-Party][CI] Add accouts to CI group

2015-10-16 Thread Watanabe, Isao

Hello, Third-Party Coordinators
Cc：Ramy

Could you add the following 2 accounts to CI group, please?
Also, we will continually update the wiki.
[1]
Name: Fujitsu C-Fabric CI
Mail: lsoft-cfabri...@ml.css.fujitsu.com
Wiki: https://wiki.openstack.org/wiki/ThirdPartySystems/Fujitsu_C-Fabric_CI

[2]
Name: Fujitsu IRMC CI
Mail: lsoft-irm...@ml.css.fujitsu.com
Wiki: https://wiki.openstack.org/wiki/ThirdPartySystems/Fujitsu_IRMC_CI


Best regards,
Watanabe.isao




__
OpenStack Development Mailing 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] [packaging] liberty doesn't have caps on deps

2015-10-16 Thread Sean Dague

On 10/16/2015 04:23 AM, Thierry Carrez wrote:
> Robert Collins wrote:
>> [...]
>> BUT: we haven't (ever!) tested that the lowest versions we specify
>> work. When folk know they are adding a hard dependency on a version we
>> do raise the lower versions, but thats adhoc and best effort today.
>> I'd like to see a lower-constraints.txt reflecting the oldest version
>> that works across all of OpenStack (as a good boundary case to test) -
>> but we need to fix pip first to teach it to choose lower versions over
>> higher versions (https://github.com/pypa/pip/issues/3188 - I thought
>> I'd filed it previously but couldn't find it...)
>>
>> More generally, we don't [yet] have the testing setup to test multiple
>> versions on an ongoing basis, so we can't actually make any statement
>> other than 'upper-constraints.txt is known to work'. Note: before
>> constraints we couldn't even make *that* statement. The statement we
>> could make then was 'if you look up the change in gerrit and from that
>> the CI dvsm test run which got through the gate, then you can
>> figureout *a* version of the dependencies that worked.
> 
> And that is the critical bit. The system we had in kilo and before may
> appear to be more practical to interpret downstream, but the assertions
> it was making were mostly untested. So the capping was a convenient
> illusion: things beyond the cap may be working, and things below the cap
> could actually be broken. At least the upper-constraints expresses
> clearly the combination that works and was tested. Combined with the
> uncapped requirements (which express what *should* be working, to the
> best of our knowledge), they make a more accurate, albeit admittedly
> more complex, set of information for downstream packagers.

And equally important is that pip only really reacts well to version
capping / pinning if you do it all at once across all your things.

When we had a cap, and raised it, we had to:

A) raise it in low level oslo libs (like oslo.config)
B) release those libraries with new caps
C) raise the cap in all the things that used that library
D) release those libraries with new caps
E) ... repeat
...
M) raise the cap in all top level openstack server projects

So a dozen library releases could easily be triggered by fixing one cap
or pin in one low level library, that were no functional changes, they
were just requirements changes. The only reason M could use the old
version of A is because pip wouldn't let you install the 2 together. Not
for any functional reasons.

-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] [neutron][stable] proactive backporting

2015-10-16 Thread Ihar Hrachyshka

Hi all,

I’d like to introduce a new initiative around stable branches for neutron 
official projects (neutron, neutron-*aas, python-neutronclient) that is 
intended to straighten our backporting process and make us more proactive in 
fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a known 
bug hits a user that consumes stable branches, but backport fixes in advance 
quickly after they hit master.

The idea is simple: every Fri I walk thru the new commits merged into master 
since last check; produce lists of bugs that are mentioned in 
Related-Bug/Closes-Bug; paste them into:

https://etherpad.openstack.org/p/stable-bug-candidates-from-master

Then I click thru the bug report links to determine whether it’s worth a 
backport and briefly classify them. If I have cycles, I also request backports 
where it’s easy (== a mere 'Cherry-Pick to' button click).

After that, those interested in maintaining neutron stable branches can take 
those bugs one by one and handle them, which means: checking where it really 
applies for backport; creating backport reviews (solving conflicts, making 
tests pass). After it’s up for review for all branches affected and applicable, 
the bug is removed from the list.

I started on that path two weeks ago, doing initial swipe thru all commits 
starting from stable/liberty spin off. If enough participants join the process, 
we may think of going back into git history to backport interesting fixes from 
stable/liberty into stable/kilo.

Don’t hesitate to ask about details of the process, and happy backporting,

Ihar


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

Re: [openstack-dev] [Fuel] Proposal to freeze old Fuel CLI

2015-10-16 Thread Aleksey Kasatkin

+1 to Sebastian. And, AFAIK, there is no user docs (or about no docs) on
CLI v2. Even for 7.0 new features were documented using CLI v1.



Aleksey Kasatkin


On Fri, Oct 16, 2015 at 3:38 PM, Igor Kalnitsky 
wrote:

> +1 to Sebastian.
>
> On Wed, Oct 14, 2015 at 12:13 PM, Sebastian Kalinowski
>  wrote:
> > Roman, this was already discussed in [1].
> > The conclusion was that we will implement new features in both places so
> > user will not have to
> > use "old" fuelclient to do some things and the "new" to others.
> > There were no progress with moving old commands to new CLI and I didn't
> seen
> > plans to do so.
> > IMHO without a detailed plan on migrating old commands to new client and
> > without a person (or people)
> > that will drive this task we *cannot* freeze old fuelclient as new one is
> > still not fully usable.
> >
> > Best,
> > Sebastian
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/070279.html
> >
> >
> > 2015-10-14 10:56 GMT+02:00 Roman Prykhodchenko :
> >>
> >> Fuelers,
> >>
> >> as you know a big effort has been put into making Fuel Client’s CLI
> better
> >> and as a result we got a new fuel2 utility with a new set of commands
> and
> >> options. Some folks still put great effort to move everything that’s
> left in
> >> the old CLI to the new CLI.
> >>
> >> Every new thing added to the old CLI moves the point where we can
> finally
> >> remove it to the future. My proposal is to do a hard code freeze for
> the old
> >> CLI and only add new stuff to the new one.
> >>
> >>
> >> - romcheg
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] Errors in neutron-server while launching VM

Hi Elena,

I am using these commands only.Please see below .

root@t1040rdb:~# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 11
Server version: 5.5.39-MariaDB Source distribution

Copyright (c) 2000, 2014, Oracle, Monty Program Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.

MariaDB [(none)]> use neutron;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [neutron]> show tables
->

show tables command is not giving any output.

..

Regards

Rahul Arora

On Fri, Oct 16, 2015 at 6:25 PM, Elena Ezhova  wrote:

> Rahul,
>
> Firstly, you have to choose a database.
>
> mysql> use neutron;
> mysql> show tables;
> mysql> select *  from networks;
>
> On Fri, Oct 16, 2015 at 3:29 PM, Rahul Arora 
> wrote:
>
>> Hi Nitish,
>>
>> When i am trying to see table "networks" in the DB.I am not able to use
>> "show tables" command to see tables.looks like it this version does not
>> suppor that.
>>
>> List of all MySQL commands:
>> Note that all text commands must be first on line and end with ';'
>> ? (\?) Synonym for `help'.
>> clear (\c) Clear the current input statement.
>> connect   (\r) Reconnect to the server. Optional arguments are db and
>> host.
>> delimiter (\d) Set statement delimiter.
>> edit  (\e) Edit command with $EDITOR.
>> ego   (\G) Send command to mysql server, display result vertically.
>> exit  (\q) Exit mysql. Same as quit.
>> go(\g) Send command to mysql server.
>> help  (\h) Display this help.
>> nopager   (\n) Disable pager, print to stdout.
>> notee (\t) Don't write into outfile.
>> pager (\P) Set PAGER [to_pager]. Print the query results via PAGER.
>> print (\p) Print current command.
>> prompt(\R) Change your mysql prompt.
>> quit  (\q) Quit mysql.
>> rehash(\#) Rebuild completion hash.
>> source(\.) Execute an SQL script file. Takes a file name as an
>> argument.
>> status(\s) Get status information from the server.
>> system(\!) Execute a system shell command.
>> tee   (\T) Set outfile [to_outfile]. Append everything into given
>> outfile.
>> use   (\u) Use another database. Takes database name as argument.
>> charset   (\C) Switch to another charset. Might be needed for processing
>> binlog with multi-byte charsets.
>> warnings  (\W) Show warnings after every statement.
>> nowarning (\w) Don't show warnings after every statement.
>>
>> For server side help, type 'help contents'
>>
>> mysql>
>>
>>
>> Can you please redirect me how i can see this?
>>
>> --
>>
>> Regards
>>
>> Rahul Arora
>>
>> On Fri, Oct 16, 2015 at 3:52 PM, nithish B 
>> wrote:
>>
>>> Hi Rahul,
>>> Is the table "networks" available in the DB? Looks like it does not
>>> exist and thus when neutron queries the DB, it returns the error.
>>> Let me know.
>>>
>>> Thanks.
>>> Nitish B.
>>>
>>> Regards,
>>> Nitish B.
>>>
>>> On Fri, Oct 16, 2015 at 3:10 PM, Rahul Arora 
>>> wrote:
>>>
 Hi Team.

 I am trying to run Openstack KILO release on my Ubuntu 14.04 x86
 machine.I am able to run all the services.i.e glance,nova.keystone,neutron
 etc successfully.

 But when i am trying to launch VM using below command manually.

 *nova boot --image 8f6e2973-c048-4445-8c31-38e159c930fc --flavor
 m1.tiny "rahul"*

 I am getting below error in *neutron-server *service.
 =


 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
 self.errorhandler(self, exc, value)
 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource   File
 "/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
 defaulterrorhandler
 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource raise
 errorclass, errorvalue
 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource 
 OperationalError:
 (OperationalError) (1054, "Unknown column 'networks.mtu' in 'field list'")
 'SELECT networks.tenant_id AS networks_tenant_id, networks.id AS
 networks_id, networks.name AS networks_name, networks.status AS
 networks_status, networks.admin_state_up AS networks_admin_state_up,
 networks.shared AS networks_shared, networks.mtu AS networks_mtu,
 networks.vlan_transparent AS networks_vlan_transparent,
 ipallocationpools_1.id AS ipallocationpools_1_id,
 ipallocationpools_1.subnet_id AS ipallocationpools_1_subnet_id,
 ipallocationpools_1.first_ip AS ipallocationpools_1_first_ip,
 ipallocationpools_1.last_ip AS ipallocationpools_1_last_ip,
 dnsnameservers_1.address AS dnsnameservers_1_address,
 dnsnameservers_1.subnet_id AS dnsnameservers_1_subnet_id,

Re: [openstack-dev] [Openstack] Errors in neutron-server while launching VM

Hi Nasir,

While doing installation/configuration when i was trying to run
neutron-server service.I got following errors.

2015-10-05 06:48:12.549 17209 TRACE neutron   File
"/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
defaulterrorhandler
2015-10-05 06:48:12.549 17209 TRACE neutron raise errorclass, errorvalue
2015-10-05 06:48:12.549 17209 TRACE neutron ProgrammingError:
(ProgrammingError) (1146, "Table 'neutron.ml2_gre_allocations' doesn't
exist") 'SELECT ml2_gre_allocations.gre_id AS ml2_gre_allocations_gre_id,
ml2_gre_allocations.allocated AS ml2_gre_allocations_allocated \nFROM
ml2_gre_allocations' ()
2015-10-05 06:48:12.549 17209 TRACE neutron

To fix this from internet i got one command to upgrade database.Below is
the command i used.

$ neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file
/etc/neutron/plugins/ml2/ml2_conf.ini upgrade head

INFO  [alembic.runtime.migration] Context impl MySQLImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
INFO  [alembic.runtime.migration] Context impl MySQLImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade  -> havana, havana_initial
INFO  [alembic.runtime.migration] Running upgrade havana -> e197124d4b9,
add unique constraint to members
/usr/lib/python2.7/site-packages/alembic/util/langhelpers.py:122:
UserWarning: Argument 'name' is now named 'constraint_name' for method
create
_unique_constraint().
  oldname, newname, fn_name
/usr/lib/python2.7/site-packages/alembic/util/langhelpers.py:122:
UserWarning: Argument 'source' is now named 'table_name' for method
create_un
ique_constraint().
  oldname, newname, fn_name
/usr/lib/python2.7/site-packages/alembic/util/langhelpers.py:122:
UserWarning: Argument 'local_cols' is now named 'columns' for method
create_u
nique_constraint().
  oldname, newname, fn_name
INFO  [alembic.runtime.migration] Running upgrade e197124d4b9 ->
1fcfc149aca4, Add a unique constraint on (agent_type, host) columns to
prevent
 a race
condition when an agent entry is 'upserted'.
INFO  [alembic.runtime.migration] Running upgrade 1fcfc149aca4 ->
50e86cb2637a, nsx_mappings
INFO  [alembic.runtime.migration] Running upgrade 50e86cb2637a ->
1421183d533f, NSX DHCP/metadata support
INFO  [alembic.runtime.migration] Running upgrade 1421183d533f ->
3d3cb89d84ee, nsx_switch_mappings
INFO  [alembic.runtime.migration] Running upgrade 3d3cb89d84ee ->
4ca36cfc898c, nsx_router_mappings
INFO  [alembic.runtime.migration] Running upgrade 4ca36cfc898c ->
27cc183af192, ml2_vnic_type
INFO  [alembic.runtime.migration] Running upgrade 27cc183af192 ->
50d5ba354c23, ml2 binding:vif_details
INFO  [alembic.runtime.migration] Running upgrade 50d5ba354c23 ->
157a5d299379, ml2 binding:profile
INFO  [alembic.runtime.migration] Running upgrade 157a5d299379 ->
3d2585038b95, VMware NSX rebranding
INFO  [alembic.runtime.migration] Running upgrade 3d2585038b95 ->
abc88c33f74f, lb stats
INFO  [alembic.runtime.migration] Running upgrade abc88c33f74f ->
1b2580001654, nsx_sec_group_mapping
INFO  [alembic.runtime.migration] Running upgrade 1b2580001654 ->
e766b19a3bb, nuage_initial
INFO  [alembic.runtime.migration] Running upgrade e766b19a3bb ->
2eeaf963a447, floatingip_status
INFO  [alembic.runtime.migration] Running upgrade 2eeaf963a447 ->
492a106273f8, Brocade ML2 Mech. Driver
INFO  [alembic.runtime.migration] Running upgrade 492a106273f8 ->
24c7ea5160d7, Cisco CSR VPNaaS
INFO  [alembic.runtime.migration] Running upgrade 24c7ea5160d7 ->
81c553f3776c, bsn_consistencyhashes
INFO  [alembic.runtime.migration] Running upgrade 81c553f3776c ->
117643811bca, nec: delete old ofc mapping tables
INFO  [alembic.runtime.migration] Running upgrade 117643811bca ->
19180cf98af6, nsx_gw_devices
INFO  [alembic.runtime.migration] Running upgrade 19180cf98af6 ->
33dd0a9fa487, embrane_lbaas_driver
INFO  [alembic.runtime.migration] Running upgrade 33dd0a9fa487 ->
2447ad0e9585, Add IPv6 Subnet properties
INFO  [alembic.runtime.migration] Running upgrade 2447ad0e9585 ->
538732fa21e1, NEC Rename quantum_id to neutron_id
INFO  [alembic.runtime.migration] Running upgrade 538732fa21e1 ->
5ac1c354a051, n1kv segment allocs for cisco n1kv plugin
/usr/lib/python2.7/site-packages/alembic/util/langhelpers.py:122:
UserWarning: Argument 'source' is now named 'source_table' for method
create_
foreign_key().
  oldname, newname, fn_name
/usr/lib/python2.7/site-packages/alembic/util/langhelpers.py:122:
UserWarning: Argument 'referent' is now named 'referent_table' for method
cre
ate_foreign_key().
  oldname, newname, fn_name
INFO  [alembic.runtime.migration] Running upgrade 5ac1c354a051 -> icehouse,
icehouse
INFO  [alembic.runtime.migration] Running upgrade icehouse -> 54f7549a0e5f,
set_not_null_peer_address
INFO  [alembic.runtime.migration] Running upgrade 54f7549a0e5f ->
1e5dd1d09b22, set_not_null_fields_lb_stats
INFO  [alembic.runtime.migration] Running upgrade 1e5dd1d09b22 ->

[openstack-dev] [sahara] Design summit schedule posted

2015-10-16 Thread Sergey Lukjanov

Hi folks,

you could find the schedule for Sahara part of design summit at
http://mitakadesignsummit.sched.org/overview/type/sahara

All etherpads -
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Sahara

Session chairs, please, fill the etherpads.

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Make libguestfs available on pypi

2015-10-16 Thread Richard W.M. Jones

On Fri, Oct 16, 2015 at 01:40:56PM +0100, Richard W.M. Jones wrote:
> On Fri, Oct 16, 2015 at 12:58:20PM +0100, Matt Thompson wrote:
> > Hi All,
> > 
> > Does anyone know if any progress has been made here?  We're doing something
> > similar to Kris and it'd be great if libguestfs could be installed directly
> > from pypi.
> 
> Good and bad news.  No movement on the PyPi sign-up / licensing issue
> as far as I'm aware, so I'm still unable to agree to uploading the
> Python bindings to PyPi.  [I tried to sign up again just now, but the
> email is taking a very long time to come through - will update here if
> there is any change]

Nope - the soul-sucking registration page is still there, so I'm
unable to agree to uploading the python bindings to PyPi.  The onus is
still (for > 1 year) on the Python Foundation to fix this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

__
OpenStack Development Mailing 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] Errors in neutron-server while launching VM

2015-10-16 Thread Elena Ezhova

Rahul,

Firstly, you have to choose a database.

mysql> use neutron;
mysql> show tables;
mysql> select *  from networks;

On Fri, Oct 16, 2015 at 3:29 PM, Rahul Arora 
wrote:

> Hi Nitish,
>
> When i am trying to see table "networks" in the DB.I am not able to use
> "show tables" command to see tables.looks like it this version does not
> suppor that.
>
> List of all MySQL commands:
> Note that all text commands must be first on line and end with ';'
> ? (\?) Synonym for `help'.
> clear (\c) Clear the current input statement.
> connect   (\r) Reconnect to the server. Optional arguments are db and host.
> delimiter (\d) Set statement delimiter.
> edit  (\e) Edit command with $EDITOR.
> ego   (\G) Send command to mysql server, display result vertically.
> exit  (\q) Exit mysql. Same as quit.
> go(\g) Send command to mysql server.
> help  (\h) Display this help.
> nopager   (\n) Disable pager, print to stdout.
> notee (\t) Don't write into outfile.
> pager (\P) Set PAGER [to_pager]. Print the query results via PAGER.
> print (\p) Print current command.
> prompt(\R) Change your mysql prompt.
> quit  (\q) Quit mysql.
> rehash(\#) Rebuild completion hash.
> source(\.) Execute an SQL script file. Takes a file name as an
> argument.
> status(\s) Get status information from the server.
> system(\!) Execute a system shell command.
> tee   (\T) Set outfile [to_outfile]. Append everything into given
> outfile.
> use   (\u) Use another database. Takes database name as argument.
> charset   (\C) Switch to another charset. Might be needed for processing
> binlog with multi-byte charsets.
> warnings  (\W) Show warnings after every statement.
> nowarning (\w) Don't show warnings after every statement.
>
> For server side help, type 'help contents'
>
> mysql>
>
>
> Can you please redirect me how i can see this?
>
> --
>
> Regards
>
> Rahul Arora
>
> On Fri, Oct 16, 2015 at 3:52 PM, nithish B 
> wrote:
>
>> Hi Rahul,
>> Is the table "networks" available in the DB? Looks like it does not exist
>> and thus when neutron queries the DB, it returns the error.
>> Let me know.
>>
>> Thanks.
>> Nitish B.
>>
>> Regards,
>> Nitish B.
>>
>> On Fri, Oct 16, 2015 at 3:10 PM, Rahul Arora 
>> wrote:
>>
>>> Hi Team.
>>>
>>> I am trying to run Openstack KILO release on my Ubuntu 14.04 x86
>>> machine.I am able to run all the services.i.e glance,nova.keystone,neutron
>>> etc successfully.
>>>
>>> But when i am trying to launch VM using below command manually.
>>>
>>> *nova boot --image 8f6e2973-c048-4445-8c31-38e159c930fc --flavor m1.tiny
>>> "rahul"*
>>>
>>> I am getting below error in *neutron-server *service.
>>> =
>>>
>>>
>>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource
>>> self.errorhandler(self, exc, value)
>>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource   File
>>> "/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
>>> defaulterrorhandler
>>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource raise
>>> errorclass, errorvalue
>>> 2015-10-06 02:29:53.894 8064 TRACE neutron.api.v2.resource OperationalError:
>>> (OperationalError) (1054, "Unknown column 'networks.mtu' in 'field list'")
>>> 'SELECT networks.tenant_id AS networks_tenant_id, networks.id AS
>>> networks_id, networks.name AS networks_name, networks.status AS
>>> networks_status, networks.admin_state_up AS networks_admin_state_up,
>>> networks.shared AS networks_shared, networks.mtu AS networks_mtu,
>>> networks.vlan_transparent AS networks_vlan_transparent,
>>> ipallocationpools_1.id AS ipallocationpools_1_id,
>>> ipallocationpools_1.subnet_id AS ipallocationpools_1_subnet_id,
>>> ipallocationpools_1.first_ip AS ipallocationpools_1_first_ip,
>>> ipallocationpools_1.last_ip AS ipallocationpools_1_last_ip,
>>> dnsnameservers_1.address AS dnsnameservers_1_address,
>>> dnsnameservers_1.subnet_id AS dnsnameservers_1_subnet_id,
>>> subnetroutes_1.destination AS subnetroutes_1_destination,
>>> subnetroutes_1.nexthop AS subnetroutes_1_nexthop, subnetroutes_1.subnet_id
>>> AS subnetroutes_1_subnet_id, subnets_1.tenant_id AS subnets_1_tenant_id,
>>> subnets_1.id AS subnets_1_id, subnets_1.name AS subnets_1_name,
>>> subnets_1.network_id AS subnets_1_network_id, subnets_1.subnetpool_id AS
>>> subnets_1_subnetpool_id, subnets_1.ip_version AS subnets_1_ip_version,
>>> subnets_1.cidr AS subnets_1_cidr, subnets_1.gateway_ip AS
>>> subnets_1_gateway_ip, subnets_1.enable_dhcp AS subnets_1_enable_dhcp,
>>> subnets_1.shared AS subnets_1_shared, subnets_1.ipv6_ra_mode AS
>>> subnets_1_ipv6_ra_mode, subnets_1.ipv6_address_mode AS
>>> subnets_1_ipv6_address_mode, externalnetworks_1.network_id AS
>>> externalnetworks_1_network_id \nFROM networks LEFT OUTER JOIN
>>> externalnetworks ON networks.id = externalnetworks.network_id LEFT
>>> OUTER JOIN

Re: [openstack-dev] [all][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

On 16/10/15 13:53, Christian Berendt wrote:
> On 10/16/2015 01:46 PM, Neil Jerram wrote:
>> I'd be happy to submit a fix for this, but I haven't yet found which
>> project generates this URL.  Can someone advise?
> The developer documentations use the oslosphinx
> theme.(http://git.openstack.org/cgit/openstack/oslosphinx). The
> mentioned URL is generated in
> https://github.com/openstack/oslosphinx/blob/master/oslosphinx/__init__.py#L20-L36.
> Probably there is something wrong.

Well, it would appear that 'git config --local --get remote.origin.url'
on the docs build machine gives a URL whose path includes a leading /p. 
But there isn't any /p in the Git URLs currently advertised on
https://git.openstack.org/cgit/.  And URLs with /p added don't appear to
be valid.  For example:

neil@nj-ubuntu:~/calico/networking-calico$ git ls-remote
git://git.openstack.org/openstack/ironic | head -15
5ca6e64e3387bce287e21ce8da3ed03f9537ae7eHEAD
7fea52b4d107efcd4ee1570870f6b6c1a7307c10refs/changes/00/115300/1
52cfde5dbefdbe619784c3302ea21a198a48be8erefs/changes/00/115300/2
7c765279a4eb577d03dfa4e640d008331f67626arefs/changes/00/115300/3
11501290b3acdd27cce4eb6a3cea50354492aa95refs/changes/00/115600/1
f77f01c97585175e2659960c82dc576609656d38refs/changes/00/115600/10
34fa5519bd2923caa1b524942e3f30cb6eb85936refs/changes/00/115600/11
b76ed28657b3dcd6bb322d565728ad485c95688arefs/changes/00/115600/2
34eca7eb274f54526e4e0cdb89cfeecffa75e8aarefs/changes/00/115600/3
c7f3b2591acc143c0fbb08ae9f7cf0fbc6d252cfrefs/changes/00/115600/4
7589dd01adbb9a22f921c73da571038b1a662f2frefs/changes/00/115600/5
e03459f1d9ed1a8f0530acece486834fafc7fd35refs/changes/00/115600/6
3e3ace091c6f813b3a074fe4b008a07b33b71bd2refs/changes/00/115600/7
9f2516d4e13467a1a45eb4f33884c3cec1b21b44refs/changes/00/115600/8
154a97bc36c0758448f2f104ca0eb53276bfda5frefs/changes/00/115600/9

neil@nj-ubuntu:~/calico/networking-calico$ git ls-remote
git://git.openstack.org/p/openstack/ironic
fatal: remote error: access denied or repository not exported:
/p/openstack/ironic

I'm afraid I'm stuck, then.  Any thoughts?

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] [packaging] liberty doesn't have caps on deps

Excerpts from Matthew Thode's message of 2015-10-15 17:40:27 -0500:
> On 10/15/2015 05:29 PM, Robert Collins wrote:
> > On 16 October 2015 at 11:21, Matthew Thode  
> > wrote:
> >> On 10/15/2015 05:12 PM, Robert Collins wrote:
> >>> On 16 October 2015 at 08:10, Matthew Thode  
> >>> wrote:
>  On 10/15/2015 02:04 PM, Robert Collins wrote:
> >>> ...
> >> Where are my caps?
> >
> > The known good versions of dependencies for liberty are
> > http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/liberty
> >
>  That's good, does that represent an upper constraint for the lower
>  constraint imposed by by the package?  Why is this kept separate?
>  Keeping it separate means that it's not trivial to merge them with
>  what's in each package's requirements.
> >>>
> >>> It represents *one* known good combination of packages. We know that
> >>> that combination passed CI, and we then do all our tests with it. To
> >>> change it, we run it past CI and only move onto using the new set when
> >>> its passed CI.
> >>>
> >>> If we merged it to each packages requirements, we'd reintroduce the
> >>> deadlock that caused so much grief only 6 months back - I don't see
> >>> any reason, desire, or tolerance for doing that upstream.
> >>>
> >>> Its kept separate because it requires 2N commits to shift known-good
> >>> caps around for N repos using per-repo rules.
> >>>
> >>> With hundreds of repositories, it takes us hundreds of commits in two
> >>> batches - and a round trip time of 2 hours per batch (check + gate) to
> >>> shift *a single* requirement. With hundreds of dependencies, thats an
> >>> intolerable amount of overhead.
> >>>
> >>
> >> ya, that is annoying, unfortunately packages don't need to know *ONE*
> >> good combination, they need to know them all, or at least the cap.  What
> >> you are basically doing is shifting all of this extra work onto the
> >> packagers, in fact I wouldn't be surprised if they needed to start
> >> vendoring all of openstack in a virtualenv instead of doing actual 
> >> packages.
> > 
> > Here's an example of the havoc caps cause:
> >  https://review.openstack.org/#/c/234862/
> > 
> > I don't understand the statement about shifting work. Previously the
> > situation was that you had to guess whether a given release of a
> > dependency (both internal and external) worked with e.g. liberty.
> > 
> > Now there is an explicit list of what works.
> > 
> > Isn't that *better* ?
> > 
> Yes, it's good to know what works, does that show multiple versions of
> the same package when multiple are known to work?  If so I can build a
> range from that.  It's not better as it is because I still don't know
> where liberty ends and mitaka begins.  Is there any place I can find that?

In terms of deliverables we're calling part of liberty vs. mitaka,
you can find them in the openstack/releases repository in the YAML
files in the deliverables directory. The results are published to
http://docs.openstack.org/releases/ for human consumption.

Doug

> 
> >> My question remains though, if someone pip installs nova liberty, will
> >> it pull in deps from mitaka?  As it is now, without caps I cannot
> >> reliably package openstack, do you have a solution? I should probably
> >> start removing the liberty packages I did package since upstream seems
> >> so hostile...
> > 
> > If you don't use the constraints file (which is pip consumable and
> > published on the web so it can be used with pip install trivially)
> > then yes, it will install the latest versions of all packages which
> > are presumed to be doing backwards compatible changes. Things that we
> > *know* are going to be broken still get caps - and we accept the cost
> > of the 2-step dance needed to raise them.
> > 
> 
> What about a daily or weekly check without the constraints file so you
> know when something breaks?  This would allow you to at least know when
> you need to place caps and I could consume that.  I'm fine with leaving
> caps off.  If I can consume mitaka deps in liberty then that's great :D
> 
> > The big question here is, I think, 'should we assume OpenStack
> > originated dependencies are better or worse than third party
> > dependencies?' Third party dependencies we presume are backwards
> > compatible (and will thus only break by mistake, which constraints
> > guards against) unless we have reason not to - and we have open ended
> > deps on them. This is where the spec about clients libraries is aimed.
> > 
> > It makes me very sad to know that you consider what we've done as
> > hostile. We did it for a bunch of good reasons:
> > 
> >  - safer release process
> >  - smoother updates for [apt, rpm at least] redistributors
> >  - faster turnaround of dependency usage in CI
> >  - step on the path to testing lower bounds
> >  - step on the path to alignment with upstream packaging tooling
> > 
> > -Rob
>

Re: [openstack-dev] Make libguestfs available on pypi

2015-10-16 Thread Richard W.M. Jones

On Fri, Oct 16, 2015 at 01:40:56PM +0100, Richard W.M. Jones wrote:
> On Fri, Oct 16, 2015 at 12:58:20PM +0100, Matt Thompson wrote:
> > Hi All,
> > 
> > Does anyone know if any progress has been made here?  We're doing something
> > similar to Kris and it'd be great if libguestfs could be installed directly
> > from pypi.
> 
> Good and bad news.  No movement on the PyPi sign-up / licensing issue
> as far as I'm aware, so I'm still unable to agree to uploading the
> Python bindings to PyPi.  [I tried to sign up again just now, but the
> email is taking a very long time to come through - will update here if
> there is any change]

It looks as if I managed to sign up to the PyPi account without the
soul-sucking licensing agreement.  As a result, I'll be able to upload
the Python bindings in the next few days.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

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

Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11

2015-10-16 Thread Markus Zoeller

On 10/15/2015 11:36 PM, Flavio Percoco wrote:
> >On 15/10/15 17:42 +0200, Markus Zoeller wrote:
> >For spotting possible trivial bug fixes the new query option "delta"
> >will be useful. For example: "status:open delta:<100"
> >
> >Would it be possible to create a "prio" label to help sorting out 
stuff?
> >If I understand [1] correctly, we could have something like like:
> >
> >[label "Prio"]
> >function = NoOp
> >value = 0 Undecided
> >value = 1 critical
> >value = 2 high
> >value = 3 trivialfix
> >
> >For example, this would allow to create a query with
> >
> >"status:open label:Prio=3"
> >
> >to get all reviews for trivial bug fixes.
> 
> +1
> 
> In glance we're currently grouping blueprints, bugs and random
> patches. It'd be AWESOME, to have a way to tag priorities on patches.
> 
> I guess topics could be used but those are overwritten on every new
> PS.

The topics survive a new patch set, as far as I observed it. Nova used
this approach in Kilo too [1] but I didn't find such a thing for Liberty
and I don't know how well this worked. When I think a second time about
my idea above, I'm unclear which impact that would have on the general
review process and this thread is probably not the right one to discuss
this. I have to think more about this. 

[1] 
https://github.com/stackforge/gerrit-dash-creator/blob/master/dashboards/nova-kilo-priorities.dash


__
OpenStack Development Mailing 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] [release] opening stable/liberty

2015-10-16 Thread Dave McCowan (dmccowan)

Hi Doug--
   I will fix the Barbican branch.
   https://review.openstack.org/#/c/235157/
--Dave

On 10/15/15, 2:30 PM, "Doug Hellmann"  wrote:

>One of the first steps for opening stable/liberty is to update the
>version settings in the branches to no longer use pre-versioning.
>Thierry submitted a bunch of patches to projects [0], and some are
>merging now.
>
>Others are running into test failures, though, and need attention from
>project teams. We need release liaisons to look at them, or find someone
>to look at them, and take over the patches to add whatever fixes are
>needed so we can land them.
>
>Please respond to this thread if you're taking over the patch for your
>project so we know who is working on each.
>
>Doug
>
>[0] 
>https://review.openstack.org/#/q/branch:stable/liberty+topic:next-liberty-
>stable,n,z
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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] [QA] Design Summit Schedule

2015-10-16 Thread Matthew Treinish

On Fri, Oct 16, 2015 at 01:21:04PM +0200, Dmitry Tantsur wrote:
> On 10/15/2015 06:42 PM, Matthew Treinish wrote:
> >
> >Hi Everyone,
> >
> >I just pushed up the QA schedule for design summit:
> >
> >https://mitakadesignsummit.sched.org/overview/type/qa
> >
> >Let me know if there are any big schedule conflicts or other issues, so we 
> >can
> >work through the problem.
> 
> Hi!
> 
> I wonder if it's possible to move "QA: Tempest Microversion Support and
> Testing" one slot down (to 3:40), so that Ironic people can attend.

Ok sure, not overlapping that session with ironic is probably a good idea. I
just swapped the microversion session with the OpenStack Health Dashboard
session. There didn't seem to be any other potential conflicts with swapping
those 2 fishbowls. Hopefully this won't cause other issues for people.

Thanks,

Matt 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

Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

2015-10-16 Thread Alexey Elagin


Hello Simon!

We are going to remove plugins' functional tests from fuel-qa because 
this tests don't use for our plugins CI process.


__
OpenStack Development Mailing 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][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer

On 16/10/15 15:51, Jeremy Stanley wrote:
> On 2015-10-16 10:20:17 -0400 (-0400), Doug Hellmann wrote:
>> Excerpts from Neil Jerram's message of 2015-10-16 13:10:41 +:
> [...]
>>> Well, it would appear that 'git config --local --get remote.origin.url'
>>> on the docs build machine gives a URL whose path includes a leading /p. 
>>> But there isn't any /p in the Git URLs currently advertised on
>>> https://git.openstack.org/cgit/.
> [...]
>> Is there a gerrit remote with a better URL?
> I'd rather not first jump to conclusions on this. I checked an
> arbitrary job workspace on one of the worker nodes and `git config
> --local --get remote.origin.url` isn't returning anything with a /p
> in it. We should probably step through the process to determine
> where in the job that string is actually being set.

Sorry, you're right.  I did jump too quickly to a conclusion there.

>
> For starters, what is the goal of that link? Should it be a
> browseable version of the repository or a clone URL? If it's
> supposed to be browseable, then querying git remote is a bad idea
> regardless.

Surely it must be intended to be browseable?  If it was intended as a
clone URL, shouldn't it be presented in plain text, instead of as a link?

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-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

2015-10-16 Thread Simon Pasquier

Hello Fuelers!

I'd like to discuss something that I feel is important to improve the
quality of the Fuel plugins. Currently, the functional tests for Fuel
plugins are located in the fuel-qa project [1]. IMO this isn't viable in
the (mid) long term since:
- the fuel-qa cores have little knowledge about what a particular plugin is
supposed to do so they mostly focus on the code style.
- It increases the review load on the fuel-qa team.
- It doesn't encourage plugin developers to extend their test coverage
because it takes time to get a patch approved (no blame on the fuel-qa team
here).
- the fuel-qa repository gets cluttered with tests that aren't about the
Fuel core.

At some point, it was discussed that these functional tests should live in
the plugin's project itself. Is that still an option? What's missing to
make that happen?

FWIW, I would be more than happy to help kicking this off.

BR,
Simon

[1]
https://github.com/stackforge/fuel-qa/tree/2b7ce18e799d7096e589083246a2699c0cd6912e/fuelweb_test/tests/plugins
__
OpenStack Development Mailing 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] Errors in neutron-server while launching VM

2015-10-16 Thread Hinds, Luke (Nokia - GB/Bristol)

On Fri, 2015-10-16 at 20:04 +0530, EXT Rahul Arora wrote:
HI Nitish,

Actually i am running openstack kilo on my powerpc platform now.I am able to 
run it on the x86 successfully.

On the running setup i.e on x86 machine also i am having same output of the 
status command in neutron database,See below.

mysql> use neutron
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> status
--
mysql  Ver 14.14 Distrib 5.5.44, for debian-linux-gnu (i686) using readline 6.3

Connection id:381
Current database:neutron
Current user:root@localhost
SSL:Not in use
Current pager:stdout
Using outfile:''
Using delimiter:;
Server version:5.5.44-0ubuntu0.14.04.1 (Ubuntu)
Protocol version:10
Connection:127.0.0.1 via TCP/IP
Server characterset:latin1
Db characterset:utf8
Client characterset:utf8
Conn.  characterset:utf8
TCP port:3306
Uptime:1 day 3 hours 52 min 27 sec

Threads: 12  Questions: 576409  Slow queries: 0  Opens: 1600  Flush tables: 1  
Open tables: 374  Queries per second avg: 5.744

I am wondering what is the issue in powerpc.So i guess  cause is i am not able 
to run below command successfully on the powerpc.

neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file 
/etc/neutron/plugins/ml2/ml2_conf.ini upgrade head

But this command is successful in x86 machine.

On powerpc i am getting below error while running it,

raise errorclass, errorvalueegards
sqlalchemy.exc.OperationalError: (OperationalError) (1005, "Can't create table 
'neutron.nuage_routerroutes_mapping' (errno: 121)") '\nCREATE TA
BLE nuage_routerroutes_mapping (\n\tdestination VARCHAR(64) NOT NULL, 
\n\tnexthop VARCHAR(64) NOT NULL, \n\trouter_id VARCHAR(36) NOT NULL, \n\
tnuage_route_id VARCHAR(36), \n\tPRIMARY KEY (destination, nexthop, router_id), 
\n\tFOREIGN KEY(router_id) REFERENCES routers (id) ON DELETE CA
SCADE\n)ENGINE=InnoDB\n\n' ()

I am not able to solve this.Please help me on this,

..

Regards

Rahul Arora

How are you installing juno? Is it a packaged version (devstack  / ansible etc) 
or manually? It might be that you have MariaDB compiled for x86 on there 
(different instruction sets).

On Fri, Oct 16, 2015 at 7:56 PM, nithish B 
> wrote:
Rahul,
Clearly, neutron didn't create the tables right. You may have to 
re-install/re-configure neutron.

Thanks.

Regards,
Nitish B.

On Fri, Oct 16, 2015 at 7:55 PM, Rahul Arora 
> wrote:
Hi Nitish.

Below is the output of status of neutron database.Yes i am using "use neutron" 
before running the command.

MariaDB [neutron]> status
--
mysql  Ver 15.1 Distrib 5.5.39-MariaDB, for Linux (powerpc) using readline 5.1

Connection id:  42
Current database:   neutron
Current user:   root@localhost
SSL:Not in use
Current pager:  stdout
Using outfile:  ''
Using delimiter:;
Server: MariaDB
Server version: 5.5.39-MariaDB Source distribution
Protocol version:   10
Connection: Localhost via UNIX socket
Server characterset:utf8
Db characterset:utf8
Client characterset:latin1
Conn.  characterset:latin1
UNIX socket:/var/lib/mysql/mysql.sock
Uptime: 1 hour 15 min 15 sec

Threads: 11  Questions: 24713  Slow queries: 5  Opens: 164  F

On Fri, Oct 16, 2015 at 7:51 PM, nithish B 
> wrote:
Rahul,
Please check the version of MySQL/MariaDB which you are using. For quick 
reference, you can use the following command in mysql: "SHOW VARIABLES LIKE 
"%version%";"

Also, before you run "show tables", you need to select the DB to use, using 
"use ".

Thanks.

Regards,
Nitish B.

On Fri, Oct 16, 2015 at 6:41 PM, Rahul Arora 
> wrote:
Hi Nasir,

While doing installation/configuration when i was trying to run neutron-server 
service.I got following errors.

2015-10-05 06:48:12.549 17209 TRACE neutron   File 
"/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in 
defaulterrorhandler
2015-10-05 06:48:12.549 17209 TRACE neutron raise errorclass, errorvalue
2015-10-05 06:48:12.549 17209 TRACE neutron ProgrammingError: 
(ProgrammingError) (1146, "Table 'neutron.ml2_gre_allocations' doesn't exist") 
'SELECT ml2_gre_allocations.gre_id AS ml2_gre_allocations_gre_id, 
ml2_gre_allocations.allocated AS ml2_gre_allocations_allocated \nFROM 
ml2_gre_allocations' ()
2015-10-05 06:48:12.549 17209 TRACE neutron

To fix this from internet i got one command to upgrade database.Below is the 
command i used.

$ neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file

Re: [openstack-dev] Make libguestfs available on pypi

2015-10-16 Thread Matt Thompson

Rich, many thanks for the update!  I'll see if we can build libguestfs
using the steps provided.  I'll also try to reach out to the Python
Foundation to see if we can get this issue back on their radar.

Regards,
Matt

On Fri, Oct 16, 2015 at 2:50 PM, Richard W.M. Jones 
wrote:

> On Fri, Oct 16, 2015 at 01:40:56PM +0100, Richard W.M. Jones wrote:
> > On Fri, Oct 16, 2015 at 12:58:20PM +0100, Matt Thompson wrote:
> > > Hi All,
> > >
> > > Does anyone know if any progress has been made here?  We're doing
> something
> > > similar to Kris and it'd be great if libguestfs could be installed
> directly
> > > from pypi.
> >
> > Good and bad news.  No movement on the PyPi sign-up / licensing issue
> > as far as I'm aware, so I'm still unable to agree to uploading the
> > Python bindings to PyPi.  [I tried to sign up again just now, but the
> > email is taking a very long time to come through - will update here if
> > there is any change]
>
> Nope - the soul-sucking registration page is still there, so I'm
> unable to agree to uploading the python bindings to PyPi.  The onus is
> still (for > 1 year) on the Python Foundation to fix this.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Require documenting changes with versionadded and versionchanged

2015-10-16 Thread Joshua Harlow

Victor Stinner wrote:

Le 15/10/2015 17:54, Joshua Harlow a écrit :

and it is pretty hard to get those two numbers right, especially with
weekly releases and not knowing when a review will merge... I'm not
saying we shouldn't try to do this, but we just have to figure out how
to do it in a smart way.

I hope that we will not release *too* frequently. Oslo libraries are
supposed to be somehow "stable" :-) Past history showed that any minor
change has major impact on the OpenStack CI ;-)

Stability != releasing frequently (which is a good thing to do);
stability IMHO is more about having stable API(s) but even with said
API(s) bugs happen and new things get added. Overall point taken, we
have to be careful (but I would hope this isn't unique to oslo, everyone
in the community should be careful because in reality everyone is
producing stable API(s) for consumption by someone else).

If we have to choose between "documenting changes with the wrong version
number" and "don't document changes", I pick the wrong version. IHMO
it's better than doc at all.

As I replied to Brant, I don't expect so much issues between doc and
version numbers.

The most basic check is to compute the diff since the previous release
and check manually all versionadded and versionchanged.

Perhaps there need to be a gerrit based way to add these, so for example
a review submitter would write:

".. versionadded:: $FILL_ME_IN_WHEN_MERGED" and ".. versionchanged::
$FILL_ME_IN_WHEN_MERGED" or something, and gerrit when merging code
would change those into real numbers...

+1 I remember that from CVS to, damn, that was a long time ago, ha.

Victor

Re: [openstack-dev] [neutron][stable] proactive backporting

2015-10-16 Thread Salvatore Orlando

This sounds like a pretty decent idea to me. Considering Neutron's patch
merge rate this activity should hopefully not take a consistent chunk of
your Friday.
It might also make sense to ask contributors to resume the habit of tagging
bugs with 'backport-potential' even if not in the RC period.

I am glad to offer my help as well in evaluating "backport worthiness", and
the process you outlined looks very good to me.
If there's any discussion needed for assessing whether a bug fix should be
backported or not, we could either use the etherpad or launchpad, with a
slight preference for launchpad.

Salvatore

On 16 October 2015 at 16:19, Kyle Mestery  wrote:

> On Fri, Oct 16, 2015 at 7:33 AM, Ihar Hrachyshka 
> wrote:
>
>> Hi all,
>>
>> I’d like to introduce a new initiative around stable branches for neutron
>> official projects (neutron, neutron-*aas, python-neutronclient) that is
>> intended to straighten our backporting process and make us more proactive
>> in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a
>> known bug hits a user that consumes stable branches, but backport fixes in
>> advance quickly after they hit master.
>>
>> The idea is simple: every Fri I walk thru the new commits merged into
>> master since last check; produce lists of bugs that are mentioned in
>> Related-Bug/Closes-Bug; paste them into:
>>
>> https://etherpad.openstack.org/p/stable-bug-candidates-from-master
>>
>> Then I click thru the bug report links to determine whether it’s worth a
>> backport and briefly classify them. If I have cycles, I also request
>> backports where it’s easy (== a mere 'Cherry-Pick to' button click).
>>
>> After that, those interested in maintaining neutron stable branches can
>> take those bugs one by one and handle them, which means: checking where it
>> really applies for backport; creating backport reviews (solving conflicts,
>> making tests pass). After it’s up for review for all branches affected and
>> applicable, the bug is removed from the list.
>>
>> I started on that path two weeks ago, doing initial swipe thru all
>> commits starting from stable/liberty spin off. If enough participants join
>> the process, we may think of going back into git history to backport
>> interesting fixes from stable/liberty into stable/kilo.
>>
>> Don’t hesitate to ask about details of the process, and happy backporting,
>>
>> Wow, this is a great idea Ihar! Thanks for taking this on! Count me in on
> helping with this effort as well.
>
> Thanks,
> Kyle
>
>
>> Ihar
>>
>> __
>> OpenStack Development Mailing 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] Proposal to freeze old Fuel CLI

2015-10-16 Thread Tomasz Napierala

+1 here. There were very little implemented in the new client in terms of 
feature parity, it’s not ready to be real replacement yet.


> On 14 Oct 2015, at 11:13, Sebastian Kalinowski  
> wrote:
> 
> Roman, this was already discussed in [1].
> The conclusion was that we will implement new features in both places so user 
> will not have to
> use "old" fuelclient to do some things and the "new" to others.
> There were no progress with moving old commands to new CLI and I didn't seen 
> plans to do so.
> IMHO without a detailed plan on migrating old commands to new client and 
> without a person (or people)
> that will drive this task we *cannot* freeze old fuelclient as new one is 
> still not fully usable.
> 
> Best,
> Sebastian
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070279.html
> 
> 
> 2015-10-14 10:56 GMT+02:00 Roman Prykhodchenko :
> Fuelers,
> 
> as you know a big effort has been put into making Fuel Client’s CLI better 
> and as a result we got a new fuel2 utility with a new set of commands and 
> options. Some folks still put great effort to move everything that’s left in 
> the old CLI to the new CLI.
> 
> Every new thing added to the old CLI moves the point where we can finally 
> remove it to the future. My proposal is to do a hard code freeze for the old 
> CLI and only add new stuff to the new one.
> 
> 
> - romcheg
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland







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

Re: [openstack-dev] [Openstack] Errors in neutron-server while launching VM

HI Nitish,

Actually i am running openstack kilo on my powerpc platform now.I am able
to run it on the x86 successfully.

On the running setup i.e on x86 machine also i am having same output of the
status command in neutron database,See below.

mysql> use neutron
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> status
--
mysql  Ver 14.14 Distrib 5.5.44, for debian-linux-gnu (i686) using readline
6.3

Connection id:381
Current database:neutron
Current user:root@localhost
SSL:Not in use
Current pager:stdout
Using outfile:''
Using delimiter:;
Server version:5.5.44-0ubuntu0.14.04.1 (Ubuntu)
Protocol version:10
Connection:127.0.0.1 via TCP/IP
Server characterset:latin1
Db characterset:utf8
Client characterset:utf8
Conn.  characterset:utf8
TCP port:3306
Uptime:1 day 3 hours 52 min 27 sec

Threads: 12  Questions: 576409  Slow queries: 0  Opens: 1600  Flush tables:
1  Open tables: 374  Queries per second avg: 5.744


I am wondering what is the issue in powerpc.So i guess  cause is i am not
> able to run below command successfully on the powerpc.




> *neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file
> /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head*


But this command is successful in x86 machine.

On powerpc i am getting below error while running it,

raise errorclass, errorvalueegards
sqlalchemy.exc.OperationalError: (OperationalError) (1005, "Can't create
table 'neutron.nuage_routerroutes_mapping' (errno: 121)") '\nCREATE TA
BLE nuage_routerroutes_mapping (\n\tdestination VARCHAR(64) NOT NULL,
\n\tnexthop VARCHAR(64) NOT NULL, \n\trouter_id VARCHAR(36) NOT NULL, \n\
tnuage_route_id VARCHAR(36), \n\tPRIMARY KEY (destination, nexthop,
router_id), \n\tFOREIGN KEY(router_id) REFERENCES routers (id) ON DELETE CA
SCADE\n)ENGINE=InnoDB\n\n' ()


I am not able to solve this.Please help me on this,

..

Regards

Rahul Arora






>
>

On Fri, Oct 16, 2015 at 7:56 PM, nithish B  wrote:

> Rahul,
> Clearly, neutron didn't create the tables right. You may have to
> re-install/re-configure neutron.
>
> Thanks.
>
> Regards,
> Nitish B.
>
> On Fri, Oct 16, 2015 at 7:55 PM, Rahul Arora 
> wrote:
>
>> Hi Nitish.
>>
>> Below is the output of status of neutron database.Yes i am using "use
>> neutron" before running the command.
>>
>> MariaDB [neutron]> status
>> --
>> mysql  Ver 15.1 Distrib 5.5.39-MariaDB, for Linux (powerpc) using
>> readline 5.1
>>
>> Connection id:  42
>> Current database:   neutron
>> Current user:   root@localhost
>> SSL:Not in use
>> Current pager:  stdout
>> Using outfile:  ''
>> Using delimiter:;
>> Server: MariaDB
>> Server version: 5.5.39-MariaDB Source distribution
>> Protocol version:   10
>> Connection: Localhost via UNIX socket
>> Server characterset:utf8
>> Db characterset:utf8
>> Client characterset:latin1
>> Conn.  characterset:latin1
>> UNIX socket:/var/lib/mysql/mysql.sock
>> Uptime: 1 hour 15 min 15 sec
>>
>> Threads: 11  Questions: 24713  Slow queries: 5  Opens: 164  F
>>
>> On Fri, Oct 16, 2015 at 7:51 PM, nithish B 
>> wrote:
>>
>>> Rahul,
>>> Please check the version of MySQL/MariaDB which you are using. For quick
>>> reference, you can use the following command in mysql: "*SHOW VARIABLES
>>> LIKE "%version%";"*
>>>
>>> Also, before you run "show tables", you need to select the DB to use,
>>> using "use ".
>>>
>>> Thanks.
>>>
>>>
>>> Regards,
>>> Nitish B.
>>>
>>> On Fri, Oct 16, 2015 at 6:41 PM, Rahul Arora 
>>> wrote:
>>>
 Hi Nasir,

 While doing installation/configuration when i was trying to run
 neutron-server service.I got following errors.

 2015-10-05 06:48:12.549 17209 TRACE neutron   File
 "/usr/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in
 defaulterrorhandler
 2015-10-05 06:48:12.549 17209 TRACE neutron raise errorclass,
 errorvalue
 2015-10-05 06:48:12.549 17209 TRACE neutron ProgrammingError:
 (ProgrammingError) (1146, "Table 'neutron.ml2_gre_allocations' doesn't
 exist") 'SELECT ml2_gre_allocations.gre_id AS ml2_gre_allocations_gre_id,
 ml2_gre_allocations.allocated AS ml2_gre_allocations_allocated \nFROM
 ml2_gre_allocations' ()
 2015-10-05 06:48:12.549 17209 TRACE neutron

 To fix this from internet i got one command to upgrade database.Below
 is the command i used.

 $ neutron-db-manage --config-file /etc/neutron/neutron.conf
 --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head

 INFO  [alembic.runtime.migration] Context impl

Re: [openstack-dev] Scheduler proposal

2015-10-16 Thread Alec Hothan (ahothan)

On 10/15/15, 11:11 PM, "Clint Byrum"  wrote:

>Excerpts from Ed Leafe's message of 2015-10-15 11:56:24 -0700:
>> Wow, I seem to have unleashed a bunch of pent-up frustration in the 
>> community! It's great to see everyone coming forward with their ideas and 
>> insights for improving the way Nova (and, by extension, all of OpenStack) 
>> can potentially scale.
>> 
>> I do have a few comments on the discussion:
>> 
>> 1) This isn't a proposal to simply add some sort of DLM to Nova as a magic 
>> cure-all. The concerns about Nova's ability to scale have to do a lot more 
>> with the overall internal communication design.
>> 
>
>In this, we agree.
>
>> 2) I really liked the comment about "made-up numbers". It's so true: we are 
>> all impressed by such examples of speed that we sometimes forget whether 
>> speeding up X will improve the overall process to any significant degree. 
>> The purpose of my original email back in July, and the question I asked at 
>> the Nova midcycle, is if we could get some numbers that would be a target to 
>> shoot for with any of these experiments. Sure, I could come up with a test 
>> that shows a zillion transactions per second, but if that doesn't result in 
>> a cloud being able to schedule more efficiently, what's the point?
>>
>
>Speed is only 1 dimension. Efficiency and simplicity are two others that
>I think are harder to quantify, but are also equally important in any
>component of OpenStack.

Monty did suggest a goal with 100K nodes - which I think is moon expedition 
kind of goal given how far we are from it, but goal nevertheless ;-)
Openstack does not provide any number today outside of "massive scale" and this 
could be a problem for designers and implementors.
I think openstack is now mature enough to have to worry seriously about scale, 
and we have a very long way to go at that level.

I agree for the importance of simplicity and efficiency. But lets also add 
operational requirements such as ease of deployment and ease of 
troubleshooting. It is more difficult for Ops to deal with too many different 
technologies under the cover.
My concern is we may not have sufficient oversight (from the TC) for this kind 
of project to keep it within reasonable complexity for the given requirements, 
and this is hard to achieve when the requirements are very vague.
It looks like the main area where we might need faster nova scheduling would be 
those big deployments that use nova networking (thousands of nodes) - just 
because neutron deployments just may not have enough nodes to require such 
rate. And nobody seems to know what is the targeted rate (schedules per second 
here) and what is the exact problem to solve (by exact I mean what numbers do 
we have to say that the current nova scheduling is too slow or does not scale).

>
>> 3) I like the idea of something like ZooKeeper, but my concern is how to 
>> efficiently query the data. If, for example, we had records for 100K compute 
>> nodes, would it be possible to do the equivalent of "SELECT * FROM resources 
>> WHERE resource_type = 'compute' AND free_ram_mb >= 2048 AND …" - well, you 
>> get the idea. Are complex data queries possible in ZK? I haven't been able 
>> to find that information anywhere.
>>
>
>You don't do complex queries, because you have all of the data in RAM,
>in an efficient in-RAM format. Even if each record is 50KB, we can do
>100,000 of them in 5GB. That's a drop in the bucket.

Yes

>
>> 4) It is true that even in a very large deployment, it is possible to keep 
>> all the relevant data needed for scheduling in memory. My concern is how to 
>> efficiently search that data, much like in the ZK scenario.
>> 
>
>There are a bunch of ways to do this. My favorite is to have filter
>plugins in the scheduler define what they need to index, and then
>build a B-tree for each filter as each record arrives in the main data
>structure. When scheduling requests come in, they simply walk through
>each B-tree and turn that into a set. Then read each piece of the set
>out of the main structure and sort based on whichever you want (less
>full for load balancing, most full for efficient stacking).

There are clearly things you should be doing to scale properly. Python is not 
very speedy but can be made good enough at scale using the proper algorithm 
(such as the one you propose).
Furthermore, it can be made to run much faster - close to native speed - with 
proper design and the use of the proper libraries. So there is a lot that can 
be done to speed up things without having necessarily to increase complexity 
and scale out everything.

>
>> 5) Concerns about Cassandra running with OpenJDK instead of the Oracle JVM 
>> are troubling. I sent an email about this to one of the people I know at 
>> DataStax, but so far have not received a response. And while it would be 
>> great to have people contribute to OpenJDK to make it compatible, keep in 
>> mind that that would be an ongoing

Re: [openstack-dev] [packaging] liberty doesn't have caps on deps

2015-10-16 Thread Matthew Thode

On 10/15/2015 03:29 PM, Robert Collins wrote:
> On 16 October 2015 at 08:57, Doug Hellmann  wrote:
>> Excerpts from Matthew Thode's message of 2015-10-15 14:35:08 -0500:
>>> On 10/15/2015 02:17 PM, Matt Riedemann wrote:

> 
>>
>> We're going to try to cover it in
>> http://mitakadesignsummit.sched.org/event/27c17a3c35d72997b372ddf4759fe1be#.ViAE67SO820
>> but we have a lot of other things to fit into that session so I want to
>> put this one last so we don't derail the other discussions.
> 
> I thought it was
> http://mitakadesignsummit.sched.org/event/0a2307779b4ab81892ba24de379e9dcc#.ViAMfd94u00
> that it was slated for, where its squarely on topic :)
> 
> -Rob
> 
I'd be nice if we can get this sorted, personally I can't make it to
Friday afternoon but I would like to go to wherever this happens.

-- 
-- Matthew Thode (prometheanfire)

__
OpenStack Development Mailing 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][docs] Incorrect '/p' in Project Source URLs on docs.openstack.org/developer