Re: [openstack-dev] ERROR : openstack Forbidden (HTTP 403)

[Emilien Macchi]

It looks like you're using packstack. You'll probably get more attention on
RDO mailing list or with a tag in your subject.

Regarding the error, I would like to see at keystone logs please.

---
Emilien Macchi
On Oct 15, 2015 12:21 PM, "Dhvanan Shah"  wrote:

> Hi,
> I have not been able to resolve it. The problem of "OpenStack Forbidden
> (HTTP 403) still persists.
>
> ERROR : Error appeared during Puppet run: 10.16.37.221_keystone.pp
> Error:
> /Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_user[neutron]:
> Could not evaluate: Execution of '/usr/bin/openstack token issue --format
> value' returned 1: WARNING: keystoneclient.auth.identity.generic.base
> Discovering versions from the identity service failed when creating the
> password plugin. Attempting to determine version from URL.
> You will find full trace in log
> /var/tmp/packstack/20151015-212559-xwC1zD/manifests/10.16.37.221_keystone.pp.log
>
> Could someone please help me with this?
>
>
>
> On Mon, Oct 12, 2015 at 5:16 PM, Dhvanan Shah  wrote:
>
>> Resolved it.
>> The no_proxy env var needs to be set if your computer is located behind a
>> authenticating proxy infrastructure.
>>
>> Source :
>>
>> https://ask.openstack.org/en/question/67203/kilo-deployment-using-packstack-fails-with-403-error-on-usrbinopenstack-service-list/
>>
>> On Mon, Oct 12, 2015 at 3:12 PM, Dhvanan Shah  wrote:
>>
>>> Hi,
>>>
>>> I am getting this error while installing Openstack on Centos.
>>> ERROR : Error appeared during Puppet run: 10.16.37.221_keystone.pp
>>> Error: Could not prefetch keystone_service provider 'openstack':
>>> Execution of '/usr/bin/openstack service list --quiet --format csv --long'
>>> returned 1: ERROR: openstack Forbidden (HTTP 403)
>>>
>>> I've checked the permissions of the the executable files and they are
>>> not the problem. So I'm not sure why I'm forbidden from executing this.
>>> Could use some help!
>>>
>>> --
>>> Dhvanan Shah
>>>
>>
>>
>>
>> --
>> Dhvanan Shah
>>
>
>
>
> --
> Dhvanan Shah
>
> __
> OpenStack Development Mailing 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

[Mike Spreitzer]

"Sean M. Collins"  wrote on 10/16/2015 01:03:53 PM:

> From: "Sean M. Collins" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/16/2015 01:12 PM
> Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> questions about configuring DevStack to use Neutron
> 
> 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.

Thanks.  I am going to do some more tests in the interim, to see what I 
can add.

Thanks,
Mike



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

Re: [openstack-dev] [neutron][networking-ovn][l3] Add/delete router interface

[Ben Pfaff]

On Fri, Oct 16, 2015 at 07:05:44PM -0700, Chandra Sekhar Vejendla wrote:
> The reason for the failure of these tests has got to do with the way
> OVN handles router interface. In openstack multiple subnets can be
> added to a network and for each of these subnets the router interface
> has to be explicitly configured. So for a given network there can be
> multiple router interfaces. With the current NB schema in OVN there
> can be only 1 router interface for a network.

I've just posted patches that support multiple routed subnets for a
logical switch, starting here:
http://openvswitch.org/pipermail/dev/2015-October/061356.html

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

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

[Oleg Gelbukh]

In short, because of this:
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/release.py#L74-L99

Unless we use dashed 2-component version where OpenStack version comes
first, followed by version of Fuel, this will break creation of a cluster
with given release.

-Oleg

On Sat, Oct 17, 2015 at 10:24 PM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:

> Why can't we use 'liberty' without 8.0?
>
> On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh  wrote:
>
>> After closer look, the only viable option in closer term seems to be
>> 'liberty-8.0' version. It does not to break comparisons that exist in the
>> code and allows for smooth transition.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Fri, Oct 16, 2015 at 5:35 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Oleg,
>>>
>>> Awesome! That's what I was looking for. :)
>>>
>>> - Igor
>>>
>>> On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh 
>>> wrote:
>>> > Igor,
>>> >
>>> > Got your question now. Coordinated point (maintenance) releases are
>>> dropped.
>>> > [1] [2]
>>> >
>>> > [1]
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html
>>> > [2]
>>> >
>>> https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases
>>> >
>>> > --
>>> > Best regards,
>>> > Oleg Gelbukh
>>> >
>>> > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky <
>>> ikalnit...@mirantis.com>
>>> > wrote:
>>> >>
>>> >> 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 <
>>> ogelb...@mirantis.com>
>>> >> >> 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
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> _

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

[Sergii Golovatiuk]

Why can't we use 'liberty' without 8.0?
On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh  wrote:

> After closer look, the only viable option in closer term seems to be
> 'liberty-8.0' version. It does not to break comparisons that exist in the
> code and allows for smooth transition.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Fri, Oct 16, 2015 at 5:35 PM, Igor Kalnitsky 
> wrote:
>
>> Oleg,
>>
>> Awesome! That's what I was looking for. :)
>>
>> - Igor
>>
>> On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh 
>> wrote:
>> > Igor,
>> >
>> > Got your question now. Coordinated point (maintenance) releases are
>> dropped.
>> > [1] [2]
>> >
>> > [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html
>> > [2]
>> >
>> https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases
>> >
>> > --
>> > Best regards,
>> > Oleg Gelbukh
>> >
>> > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> > wrote:
>> >>
>> >> 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 <
>> ogelb...@mirantis.com>
>> >> >> 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
>> >> >>

Re: [openstack-dev] [fuel] OpenStack versioning in Fuel

[Oleg Gelbukh]

After closer look, the only viable option in closer term seems to be
'liberty-8.0' version. It does not to break comparisons that exist in the
code and allows for smooth transition.

--
Best regards,
Oleg Gelbukh

On Fri, Oct 16, 2015 at 5:35 PM, Igor Kalnitsky 
wrote:

> Oleg,
>
> Awesome! That's what I was looking for. :)
>
> - Igor
>
> On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh 
> wrote:
> > Igor,
> >
> > Got your question now. Coordinated point (maintenance) releases are
> dropped.
> > [1] [2]
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html
> > [2]
> >
> https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases
> >
> > --
> > Best regards,
> > Oleg Gelbukh
> >
> > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky  >
> > wrote:
> >>
> >> 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?

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

[Dmitri Zimine]

Tony, 

You can also connect Mistral with Ansible via StackStorm and Ansible 
integration pack: 
1) StackStorm http://docs.stackstorm.com
2) https://github.com/StackStorm/st2contrib/tree/master/packs/ansible

StackStorm is open-source Apache 2.0 “wrapper” around Mistral workflow service 
that integrates 3rd party tools.

Disclosure: I work for StackStorm, I think it’s appropriate to pitch here an 
open source project that addresses the problem.

DZ.


On Oct 15, 2015, at 11:35 PM, WANG, Ming Hao (Tony T) 
 wrote:

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

[Alexander Tivelkov]

Hi folks!

Thanks all for the feedback. Yeah, this definitely needs more discussions,
and the Summit is good place to have them. Thanks to Serg for offering a
spot in the schedule.
I hope to have some PoC by that time, so we can have something which can be
demoed.

I'll try to attend the AppCatalog sessions as well. I didn't finalize my
summit schedule yet, but I'll do my best to attend as much as I can.

Thanks!


--
Regards,
Alexander Tivelkov

On Fri, Oct 16, 2015 at 10:07 PM, Christopher Aedo  wrote:

> 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 vers

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

[Tony Breeds]

On Sat, Oct 17, 2015 at 08:56:01AM +1100, Tony Breeds wrote:
 
> We actually need both https://review.openstack.org/233854 
> and https://review.openstack.org/#/c/235536  to land at this point.

Okay https://review.openstack.org/233854 has merged
https://review.openstack.org/#/c/235536 is in check now.
 
> 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.

Once 235536 merges we need either of the reviews at:
https://review.openstack.org/#/q/topic:next-liberty-stable+project:openstack/ceilometer,n,z

Yours Tony.


pgp4kmwaIJBOK.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] [neutron][networking-ovn][l3] Add/delete router interface

[Gal Sagie]

I have actually raised this issue in OVS/OVN mailing list some time ago.
(http://openvswitch.org/pipermail/dev/2015-July/058231.html)
You can read the followup discussion that went on after...

I don't see this being resolved before the summit either way, so its better
to currently disable these tests
and add the appropriate comment (and open a launchpad bug to track this)

Gal.

On Sat, Oct 17, 2015 at 5:05 AM, Chandra Sekhar Vejendla <
csvej...@us.ibm.com> wrote:

> Hello Everyone,
>
> We are currently working on a patch set to add/delete router
> interfaces in the OVN plugin. This patch was initially worked on by
> Gal Sagie (*https://review.openstack.org/#/c/206919/*
> ) and we took over
> to take it completion.
>
> There are bunch of gate tests that are failing as a result of this
> patch and we have fixed a few of them. What remain to be fixed are the
> following.
>
> test_dhcp6_stateless_from_os
> test_dualnet_multi_prefix_dhcpv6_stateless
> test_dualnet_multi_prefix_slaac
> test_multi_prefix_dhcpv6_stateless
> test_multi_prefix_slaac
> test_slaac_from_os
>
> The reason for the failure of these tests has got to do with the way
> OVN handles router interface. In openstack multiple subnets can be
> added to a network and for each of these subnets the router interface
> has to be explicitly configured. So for a given network there can be
> multiple router interfaces. With the current NB schema in OVN there
> can be only 1 router interface for a network.
>
> Most of the above test cases try to add multiple subnets in a network,
> configure router interfaces, do some connectivity tests and then clean
> up. When a router interface is configured for the first subnet all the
> DB tables are populated correctly, but when the router interface for
> the second subnet is created, it results in deletion of the router
> interface of the first subnet. So every time a router interface is
> configured for a subnet, it results in deletion of the previous
> subnets router interface, provided both the subnets belong to the same
> network. The test cases fail when they are trying to remove the router
> interface that has already been deleted from OVN NB.
>
> We considered an option to see if we can have a router port in
> "Logical Switch" table refer to multiple rows in the "Logical Router
> Port" table, but the router port in the schema is defined as a hard
> reference to uuid of the "Logical Router Port" table.
>
> Given that we want to demo l3 in Tokyo, should we consider disabling
> these tests until we figure out how to fix the issue ? Should i start
> a separate thread on ovs-dev to follow up on the issue?
>
> Thanks,
> Chandra
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

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