Re: [openstack-dev] [omni] Has the Platform9's hybrid multicloud project been abandoned?

[Blake Covarrubias]

Hi Andrea,

Omni has not been abandoned by Platform9. We're still developing Omni
internally, and are working to open source additional code as well as
improve docs so that others may more easily test & contribute.

With that said, I too would be interested in hearing how others are
enabling, or looking to enable, hybrid cloud use cases with OpenStack. I'm
not aware of any other projects with similar goals as Omni, however its
possible I just haven't been looking in the right places.

Regards,

On Mon, Nov 19, 2018 at 7:40 PM Andrea Franceschini <
andrea.franceschini...@gmail.com> wrote:

> Hello All,
>
> I'm trying to figure out if the project openstack/omni
>
> https://github.com/openstack/omni
>
> has been abandoned or superseded by another project, as it is no
> longer updated (at least not in the last year).
>
> Generally speaking, which is, if any, a project that aims at the same goal?
>
> In other words, which way should hybrid cloud be approached in Openstack?
>
> Do you have any idea/advice?
>
> Thanks a lot,
>
> Andrea
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Blake Covarrubias | Product Manager
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] about filter the flavor

[Rambo]

Hi,all


  I have an idea.Now we can't filter the special flavor according to the 
property.Can we achieve it?If we achieved this,we can filter the flavor 
according the property's key and value to filter the flavor. What do you think 
of the idea?Can you tell me more about this ?Thank you very much.__
OpenStack Development Mailing 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] [Senlin] Does Senlin support Prometheus？

[xuc...@chinacloud.com.cn]

Hi，

Senlin, Ceilometer/Aodh is currently integrated, does it support Prometheus ？


thanks

__
OpenStack Development Mailing 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] [charms] 18.11 OpenStack Charms release

[David Ames]

Announcing the 18.11 release of the OpenStack Charms.

The 18.11 charms have support for Nova cells v2 for deployments of
Queens and later. The 18.11 release also has preview features including
series upgrades and the Octavia load balancer charm. 47 bugs have been
fixed and released across the OpenStack charms.

For full details of the release, please refer to the release notes:

  https://docs.openstack.org/charm-guide/latest/1811.html

Thanks go to the following contributors for this release:

Alex Kavanagh
Andrey Grebennikov
Aymen  Frikha
Billy Olsen
Chris MacNaughton
Chris Sanders
Corey Bryant
David Ames
Dmitrii Shcherbakov
Drew Freiberger
Edward Hope-Morley
Felipe Reyes
Frode Nordahl
Fulvio Galeazzi
James Page
Liam Young
Neiloy Mukerjee
Pedro Guimarães
Pete Vander Giessen
Ryan Beisner
Vladimir Grevtsev
dongdong tao
viswesuwara nathan

__
OpenStack Development Mailing 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] [omni] Has the Platform9's hybrid multicloud project been abandoned?

[Andrea Franceschini]

Hello All,

I'm trying to figure out if the project openstack/omni

https://github.com/openstack/omni

has been abandoned or superseded by another project, as it is no
longer updated (at least not in the last year).

Generally speaking, which is, if any, a project that aims at the same goal?

In other words, which way should hybrid cloud be approached in Openstack?

Do you have any idea/advice?

Thanks a lot,

Andrea

__
OpenStack Development Mailing 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] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes??

[Sean Mooney]

On Mon, 2018-11-19 at 17:25 -0200, Rafael Folco wrote:
> (not sure if my answer has been sent, sorry if duplicate)
> I don't touch ppc for a while but AFAIK this should work as long as you run 
> full emulation (qemu, not kvm) as
> libvirt_type in nova.conf and get the qemu-system-ppc64le installed in the 
> compute node. Assume also you get the
> ppc64le image to launch your instance. Expect poor performance though.
that is my understanding also.
the perfromace is accepable but not great if you can enabled the multithread 
tcg backend instead of the default
singel tread tcg backend that is used when in qemu only mode but it still wont 
match kvm accleration or power on power
performance.

i dont think we have a way to enabel the multi thread accleration for qemu only 
backend via nova unfortunetly
it would be triavial to add but no one has asked as far as i am aware.

> 
> On Mon, Nov 19, 2018 at 4:12 PM Sean Mooney  wrote:
> > adding openstack dev.
> > On Mon, 2018-11-19 at 18:08 +, Sean Mooney wrote:
> > > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote:
> > > > On 2018-11-19 11:25, Yedhu Sastri wrote:
> > > > > Hello All,
> > > > > 
> > > > > I have some use-cases which I want to test in PowerPC 
> > > > > architecture(ppc64). As I dont have any Power machines I
> > > > > would
> > > > > like to try it with ppc64 VM's. Is it possible to run these kind of 
> > > > > VM's on my OpenStack cluster(Queens) which
> > > > > runs
> > > > > on X86_64 architecture nodes(OS RHEL 7)??
> > > > > 
> > > > 
> > > > I'm not 100% sure, but I'm 95% sure that the answer to your question is 
> > > > "No."  While there's much emulation that
> > > > occurs, the CPU isn't so much emulated, but more abstracted.  
> > > > Constructing and running a modern CPU in software
> > > > would
> > > > be non-trivial.
> > > 
> > > you can do this but not with kvm.
> > > you need to revert the virt dirver in the nova.conf back to qemu to 
> > > disable kvm to allow emulation of other
> > > plathforms.
> > > that said i have only emulated power on x86_64 using libvirt or qemu 
> > > idrectly never with openstack but i belive we
> > > used
> > > to support this i just hav enot done it personally.
> > > > 
> > > > -Ken
> > > > 
> > > > > I set the image property architecture=ppc64 to the ppc64 image I 
> > > > > uploaded to glance but no success in
> > launching VM
> > > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my 
> > > > > compute nodes and I think it is not built
> > to
> > > > > support power architecture. For testing without OpenStack I manually 
> > > > > built qemu on a x86_64 host with ppc64
> > > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I 
> > > > > dont know how to do this on my OpenStack
> > > > > cluster.
> > > > > Whether I need to manually build qemu on compute nodes with ppc64 
> > > > > support or I need to add some lines in my
> > > > > nova.conf to do this?? Any help to solve this issue would be much 
> > > > > appreciated.
> > > > > 
> > > > >  
> > > > > -- 
> > > > > Thank you for your time and have a nice day,
> > > > >  
> > > > > With kind regards,
> > > > > Yedhu Sastri
> > > > > 
> > > > > ___
> > > > > 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
> > 
> > __
> > OpenStack Development Mailing 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] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes??

[Rafael Folco]

(not sure if my answer has been sent, sorry if duplicate)
I don't touch ppc for a while but AFAIK this should work as long as you run
full emulation (qemu, not kvm) as libvirt_type in nova.conf and get the
qemu-system-ppc64le installed in the compute node. Assume also you get the
ppc64le image to launch your instance. Expect poor performance though.

On Mon, Nov 19, 2018 at 4:12 PM Sean Mooney  wrote:

> adding openstack dev.
> On Mon, 2018-11-19 at 18:08 +, Sean Mooney wrote:
> > On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote:
> > > On 2018-11-19 11:25, Yedhu Sastri wrote:
> > > > Hello All,
> > > >
> > > > I have some use-cases which I want to test in PowerPC
> architecture(ppc64). As I dont have any Power machines I
> > > > would
> > > > like to try it with ppc64 VM's. Is it possible to run these kind of
> VM's on my OpenStack cluster(Queens) which
> > > > runs
> > > > on X86_64 architecture nodes(OS RHEL 7)??
> > > >
> > >
> > > I'm not 100% sure, but I'm 95% sure that the answer to your question
> is "No."  While there's much emulation that
> > > occurs, the CPU isn't so much emulated, but more abstracted.
> Constructing and running a modern CPU in software
> > > would
> > > be non-trivial.
> >
> > you can do this but not with kvm.
> > you need to revert the virt dirver in the nova.conf back to qemu to
> disable kvm to allow emulation of other
> > plathforms.
> > that said i have only emulated power on x86_64 using libvirt or qemu
> idrectly never with openstack but i belive we
> > used
> > to support this i just hav enot done it personally.
> > >
> > > -Ken
> > >
> > > > I set the image property architecture=ppc64 to the ppc64 image I
> uploaded to glance but no success in launching VM
> > > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my
> compute nodes and I think it is not built to
> > > > support power architecture. For testing without OpenStack I manually
> built qemu on a x86_64 host with ppc64
> > > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I
> dont know how to do this on my OpenStack
> > > > cluster.
> > > > Whether I need to manually build qemu on compute nodes with ppc64
> support or I need to add some lines in my
> > > > nova.conf to do this?? Any help to solve this issue would be much
> appreciated.
> > > >
> > > >
> > > > --
> > > > Thank you for your time and have a nice day,
> > > >
> > > > With kind regards,
> > > > Yedhu Sastri
> > > >
> > > > ___
> > > > 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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Rafael Folco
Senior Software Engineer
__
OpenStack Development Mailing 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] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO

[Steven Hardy]

On Thu, Nov 15, 2018 at 3:54 PM Sagi Shnaidman  wrote:
>
> Hi,
> I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. Quique 
> is actively involved in improvements and development of TripleO and TripleO 
> CI. He also helps in other projects including but not limited to 
> Infrastructure.
> He shows a very good understanding how TripleO and CI works and I'd like 
> suggest him as core reviewer of TripleO in CI related code.
>
> Please vote!
> My +1 is here :)

+1!

__
OpenStack Development Mailing 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] Create VMs with Power architecture(ppc64) on OpenStack running on x86_64 nodes??

[Sean Mooney]

adding openstack dev.
On Mon, 2018-11-19 at 18:08 +, Sean Mooney wrote:
> On Mon, 2018-11-19 at 11:57 -0500, Ken D'Ambrosio wrote:
> > On 2018-11-19 11:25, Yedhu Sastri wrote:
> > > Hello All,
> > > 
> > > I have some use-cases which I want to test in PowerPC 
> > > architecture(ppc64). As I dont have any Power machines I
> > > would
> > > like to try it with ppc64 VM's. Is it possible to run these kind of VM's 
> > > on my OpenStack cluster(Queens) which
> > > runs
> > > on X86_64 architecture nodes(OS RHEL 7)??
> > > 
> > 
> > I'm not 100% sure, but I'm 95% sure that the answer to your question is 
> > "No."  While there's much emulation that
> > occurs, the CPU isn't so much emulated, but more abstracted.  Constructing 
> > and running a modern CPU in software
> > would
> > be non-trivial.
> 
> you can do this but not with kvm.
> you need to revert the virt dirver in the nova.conf back to qemu to disable 
> kvm to allow emulation of other
> plathforms.
> that said i have only emulated power on x86_64 using libvirt or qemu idrectly 
> never with openstack but i belive we
> used
> to support this i just hav enot done it personally.
> > 
> > -Ken
> > 
> > > I set the image property architecture=ppc64 to the ppc64 image I uploaded 
> > > to glance but no success in launching VM
> > > with those images. I am using KVM as hypervisor(qemu 2.10.0) in my 
> > > compute nodes and I think it is not built to
> > > support power architecture. For testing without OpenStack I manually 
> > > built qemu on a x86_64 host with ppc64
> > > support(qemu-ppc64) and then I am able to host the ppc64 VM. But I dont 
> > > know how to do this on my OpenStack
> > > cluster.
> > > Whether I need to manually build qemu on compute nodes with ppc64 support 
> > > or I need to add some lines in my
> > > nova.conf to do this?? Any help to solve this issue would be much 
> > > appreciated.
> > > 
> > >  
> > > -- 
> > > Thank you for your time and have a nice day,
> > >  
> > > With kind regards,
> > > Yedhu Sastri
> > > 
> > > ___
> > > 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

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

Re: [openstack-dev] [nova] Stein forum session notes

[Surya Seetharaman]

On Mon, Nov 19, 2018 at 2:39 PM Matt Riedemann  wrote:

> On 11/19/2018 3:17 AM, melanie witt wrote:
> > - Not directly related to the session, but CERN (hallway track) and
> > NeCTAR (dev ML) have both given feedback and asked that the
> > policy-driven idea for handling quota for down cells be avoided. Revived
> > the "propose counting quota in placement" spec to see if there's any
> way
> > forward here
>
> Should this be abandoned then?
>
> https://review.openstack.org/#/c/614783/
>
> Since there is no microversion impact to that change, it could be added
> separately as a bug fix for the down cell case if other operators want
> that functionality. But maybe we don't know what other operators want
> since no one else is at multi-cell cells v2 yet.
>
>
I thought the policy check was needed until the "propose counting quota in
placement"
has been implemented as a workaround and that is what the "handling down
cell" spec also proposed,
unless the former spec would be implemented within this cycle in which case
we do not need the
policy check.

-- 

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

Re: [openstack-dev] [puppet] [stable] Deprecation of newton branches

[Alex Schultz]

On Mon, Nov 19, 2018 at 1:18 AM Tobias Urdin  wrote:
>
> Hello,
>
> We've been talking for a while about the deprecation and removal of the
> stable/newton branches.
> I think it's time now that we get rid of them, we have no open patches
> and Newton is considered EOL.
>
> Could cores get back with a quick feedback and then the stable team can
> get rid of those whenever they have time.
>

yes please. let's EOL them

> Best regards
> Tobias
>
> __
> OpenStack Development Mailing 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] [Searchlight] Weekly report, Stein R-21

[Trinh Nguyen]

Hello team,

Here is the report for last week, Stein R-21. Please have a look:

https://www.dangtrinh.com/2018/11/searchlight-weekly-report-stein-r-21.html

Thanks,

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

Re: [openstack-dev] [horizon] how to get horizon related logs to syslog?

[Doug Hellmann]

Akihiro Motoki  writes:

> Hi,
>
> Horizon logging depends on Django configuration which supports full python
> logging [1].
> [1] does not provide enough examples.
> Perhaps [2] will help you (though I haven't tested it).

Based on https://docs.djangoproject.com/en/2.1/topics/logging/ it looks
like it should be possible to have Horizon's settings module disable
Django's logging configuration and call oslo.log to do that
configuration. I wonder if it would make sense to do that, for
consistency with the other services?

Doug


>
> [1] https://docs.djangoproject.com/en/2.0/topics/logging/
> [2]
> https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html
>
> Thanks,
> Akihiro
>
> 2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) <
> viktor.tikka...@nokia.com>:
>
>> Hi!
>>
>> For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic,
>> Keystone, Neutron, Nova) it was easy to get logs to syslog.
>>
>> For example for Heat something similar to this (into file
>> templates/heat.conf.j2):
>>
>> # Syslog usage
>> {% if heat_syslog_enabled %}
>> use_syslog = True
>> syslog_log_facility = LOG_LOCAL3
>> {% else %}
>> log_file = /var/log/heat/heat.log
>> {% endif %}
>>
>> But how to get Horizon related logs to syslog?
>>
>> -V.
>>
>> __
>> OpenStack Development Mailing 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

-- 
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] [Searchlight] New team meeting time

[Trinh Nguyen]

Hello team,

In order to welcome new contributors to the Searchlight project, we decided
to change the meeting time [1]:

   - Time: 13:30 UCT
   - Meeting Channel: #openstack-searchlight
   - Meeting recurrence: bi-weekly starting from 19th Nov. 2018

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-searchlight/latest.log.html

Hope that there will be new blood into the project :D

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

Re: [openstack-dev] [glance] about use shared image with each other

[Brian Rosmaita]

On 11/19/18 7:58 AM, Rambo wrote:
> Hi,all
> 
>      Recently, I want to use the shared image with each other.I find it
> isn't convenient that the producer notifies the consumer via email which
> the image has been shared and what its UUID is. In other words, why the
> image api v2 is no provision for producer-consumer communication?

The design goal for Image API v2 image sharing was to provide an
infrastructure for an "image marketplace" in an OpenStack cloud by (a)
making it easy for cloud end users to share images, and (b) making it
easy for end users not to be spammed by other end users taking advantage
of (a).  When v2 image sharing was introduced in the Grizzly release, we
did not want to dictate how producer-consumer communication would work
(because we had no idea how it would develop), so we left it up to
operators and end users to figure this out.

The advantage of email communication is that client side message
filtering is available for whatever client a particular cloud end-user
employs, and presumably that end-user knows how to manipulate the
filters without learning some new scheme (or, if the end-user doesn't
know, learning how to filter messages will apply beyond just image
sharing, which is a plus).

Also, email communication is just one way to handle producer-consumer
communication.  Some operators have adjusted their web interfaces so
that when an end-user looks at the list of images available, a
notification pops up if the end-user has any images that have been
shared with them and are still in "pending" status.  There are various
other creative things you can do using the normal API calls with regular
user credentials.

In brief, we figured that if an image marketplace evolved in a
particular cloud, producers and consumers would forge their own
relationships in whatever way made the most sense for their particular
use cases.  So we left producer-consumer communication out-of-band.

>       To make it is more convenient,  if we can add a task to change the
> member_status from "pending" to "accepted" when we share the image with
> each other. It is similar to the resize_confirm in Nova, we can control
> the time interval in config.

You could do this, but that would defeat the entire purpose of the
member statuses implementation, and hence I do not recommend it.  See
OSSN-0005 [1] for more about this issue.

Additionally, since the Ocata release, "community" images have been
available.  These do not have to be accepted by an end user (but they
also don't show up in the default image-list response).  Who can
"communitize" an image is governed by policy.

See [2] for a discussion of the various types of image sharing currently
available in the Image API v2.  The Image Service API v2 api-ref [3]
contains a brief discussion of image visibility and image sharing that
may also be useful.  Finally, the Glance Ocata release notes [4] have an
extensive discussion of image visibility.

>        Can you tell me more about this?Thank you very much!

The original design page on the wiki [5] has a list of 14 use cases we
wanted to address; looking through those will give you a better idea of
why we made the design choices we did.

Hope this helps!

cheers,
brian

[0]
http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
[1] https://wiki.openstack.org/wiki/OSSN/1226078
[2]
http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
[3] https://developer.openstack.org/api-ref/image/v2/
[4] https://docs.openstack.org/releasenotes/glance/ocata.html
[5] https://wiki.openstack.org/wiki/Glance-api-v2-image-sharing


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


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

Re: [openstack-dev] [nova] Stein forum session notes

[Matt Riedemann]

On 11/19/2018 3:17 AM, melanie witt wrote:
- Not directly related to the session, but CERN (hallway track) and 
NeCTAR (dev ML) have both given feedback and asked that the 
policy-driven idea for handling quota for down cells be avoided. Revived 
the "propose counting quota in placement" spec to see if there's any way 
forward here


Should this be abandoned then?

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

Since there is no microversion impact to that change, it could be added 
separately as a bug fix for the down cell case if other operators want 
that functionality. But maybe we don't know what other operators want 
since no one else is at multi-cell cells v2 yet.


--

Thanks,

Matt

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

Re: [openstack-dev] [nova] Can we deprecate the server backup API please?

[Matt Riedemann]

On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour 
also https://review.openstack.org/#/c/409644/


The same discussion was had in the spec for that change:

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

Ultimately it amounted to a big "meh, let's just not fix the bug but 
also no one really cares about deprecating the API either".


The only thing deprecating the API would do is signal that it probably 
shouldn't be used. We would still support it on older microversions. If 
all anyone cares about is signalling not to use the API then deprecation 
is probably fine, but I personally don't feel too strongly about it 
either way.


--

Thanks,

Matt

__
OpenStack Development Mailing 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] about use shared image with each other

[Rambo]

Hi,all


 Recently, I want to use the shared image with each other.I find it isn't 
convenient that the producer notifies the consumer via email which the image 
has been shared and what its UUID is. In other words, why the image api v2 is 
no provision for producer-consumer communication?
  To make it is more convenient,  if we can add a task to change the 
member_status from "pending" to "accepted" when we share the image with each 
other. It is similar to the resize_confirm in Nova, we can control the time 
interval in config.
   Can you tell me more about this?Thank you very much!


















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

Re: [openstack-dev] [puppet] [stable] Deprecation of newton branches

[Iury Gregory]

+1 for me

Em seg, 19 de nov de 2018 às 13:51, Mohammed Naser 
escreveu:

> With my core hat, I would give it a +1.  At this point, it has no open
> patches and the last one we merged was 7 months ago.
>
>
> https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:open
>
> https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:merged
>
> I can't speak about it as an operator as we don't run anything that old.
>
> On Mon, Nov 19, 2018 at 7:43 AM Emilien Macchi  wrote:
>
>> +1 for me, I haven't seen much interest in keeping these branches for
>> puppet modules.
>> I also would like to hear from our users though.
>>
>> On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin 
>> wrote:
>>
>>> Hello,
>>>
>>> We've been talking for a while about the deprecation and removal of the
>>> stable/newton branches.
>>> I think it's time now that we get rid of them, we have no open patches
>>> and Newton is considered EOL.
>>>
>>> Could cores get back with a quick feedback and then the stable team can
>>> get rid of those whenever they have time.
>>>
>>> Best regards
>>> Tobias
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> --
>> Emilien Macchi
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Mohammed Naser — vexxhost
> -
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mna...@vexxhost.com
> W. http://vexxhost.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygreg...@gmail.com *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [stable] Deprecation of newton branches

[Mohammed Naser]

With my core hat, I would give it a +1.  At this point, it has no open
patches and the last one we merged was 7 months ago.

https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:open
https://review.openstack.org/#/q/projects:openstack/puppet-+-project:openstack/puppet-tripleo+branch:stable/newton+is:merged

I can't speak about it as an operator as we don't run anything that old.

On Mon, Nov 19, 2018 at 7:43 AM Emilien Macchi  wrote:

> +1 for me, I haven't seen much interest in keeping these branches for
> puppet modules.
> I also would like to hear from our users though.
>
> On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin 
> wrote:
>
>> Hello,
>>
>> We've been talking for a while about the deprecation and removal of the
>> stable/newton branches.
>> I think it's time now that we get rid of them, we have no open patches
>> and Newton is considered EOL.
>>
>> Could cores get back with a quick feedback and then the stable team can
>> get rid of those whenever they have time.
>>
>> Best regards
>> Tobias
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Emilien Macchi
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [stable] Deprecation of newton branches

[Emilien Macchi]

+1 for me, I haven't seen much interest in keeping these branches for
puppet modules.
I also would like to hear from our users though.

On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin  wrote:

> Hello,
>
> We've been talking for a while about the deprecation and removal of the
> stable/newton branches.
> I think it's time now that we get rid of them, we have no open patches
> and Newton is considered EOL.
>
> Could cores get back with a quick feedback and then the stable team can
> get rid of those whenever they have time.
>
> Best regards
> Tobias
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [horizon] how to get horizon related logs to syslog?

[Akihiro Motoki]

Hi,

Horizon logging depends on Django configuration which supports full python
logging [1].
[1] does not provide enough examples.
Perhaps [2] will help you (though I haven't tested it).

[1] https://docs.djangoproject.com/en/2.0/topics/logging/
[2]
https://www.simonkrueger.com/2015/05/27/logging-django-apps-to-syslog.html

Thanks,
Akihiro

2018年11月16日(金) 18:47 Tikkanen, Viktor (Nokia - FI/Espoo) <
viktor.tikka...@nokia.com>:

> Hi!
>
> For most openstack parts (e.g. Aodh, Cinder, Glance, Heat, Ironic,
> Keystone, Neutron, Nova) it was easy to get logs to syslog.
>
> For example for Heat something similar to this (into file
> templates/heat.conf.j2):
>
> # Syslog usage
> {% if heat_syslog_enabled %}
> use_syslog = True
> syslog_log_facility = LOG_LOCAL3
> {% else %}
> log_file = /var/log/heat/heat.log
> {% endif %}
>
> But how to get Horizon related logs to syslog?
>
> -V.
>
> __
> OpenStack Development Mailing 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] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO

[Gabriele Cerami]

On 15 Nov, Sagi Shnaidman wrote:
> Hi,
> I'd like to propose Quique (@quiquell) as a core reviewer for TripleO.
> Quique is actively involved in improvements and development of TripleO and
> TripleO CI. He also helps in other projects including but not limited to
> Infrastructure.

It'll be grand.
+1

__
OpenStack Development Mailing 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] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO

[Juan Antonio Osorio Robles]

+1 on making him tripleo-ci core.


Great work!

On 11/15/18 5:50 PM, Sagi Shnaidman wrote:
> Hi,
> I'd like to propose Quique (@quiquell) as a core reviewer for TripleO.
> Quique is actively involved in improvements and development of TripleO
> and TripleO CI. He also helps in other projects including but not
> limited to Infrastructure.
> He shows a very good understanding how TripleO and CI works and I'd
> like suggest him as core reviewer of TripleO in CI related code.
>
> Please vote!
> My +1 is here :)
>
> Thanks
> -- 
> Best regards
> Sagi Shnaidman
>
> __
> OpenStack Development Mailing 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] [nova] Stein forum session notes

[melanie witt]

Hey all,

Here's some notes I took in forum sessions I attended -- feel free to 
add notes on sessions I missed.


Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018

Cheers,
-melanie


TUE
---

Cells v2 updates

- Went over the etherpad, no objections to anything
- Not directly related to the session, but CERN (hallway track) and 
NeCTAR (dev ML) have both given feedback and asked that the 
policy-driven idea for handling quota for down cells be avoided. Revived 
the "propose counting quota in placement" spec to see if there's any way 
forward here


Getting users involved in the project
=
- Disconnect between SIGs/WGs and project teams
- Too steep a first step to get involved by subscribing to ML
- People confused about how to participate

Community outreach when culture, time zones, and language differ

- Most discussion around how to synchronize real-time communication 
considering different time zones
- Best to emphasize asynchronous communication. Discussion on ML and 
gerrit reviews
- Helpful to create weekly meeting agenda in advance so contributors 
from other time zones can add notes/response to discussion items


WED
---

NFV/HPC pain points
===
Top issues for immediate action: NUMA-aware live migration (spec just 
needs re-approval), improved scheduler logging (resurrect cfriesen's 
patch and clean it up), distant third is SRIOV live migration


BFV improvements

- Went over the etherpad, no major objections to anything
- Agree: we should expose boot_index from the attachments API
- Unclear what to do about post-create delete_on_termination. Being able 
to specify it for attach sounds reasonable, but is it enough for those 
asking? Or would it end up serving no one?


Better expose what we produce
=
- Project teams should propose patches to openstack/openstack-map to 
improve their project pages
- Would be ideal if project pages included a longer paragraph explaining 
the project, have a diagram, list SIGs/WGs related to the project, etc


Blazar reservations to new resource types
=
- For nova compute hosts, reservations are done by putting reserved 
hosts into "blazar" host aggregate and then a special scheduler filter 
is used to exclude those hosts from scheduling. But how to extend that 
concept to other projects?
- Note: the nova approach will change from scheduler filter => placement 
request filter


Edge use cases and requirements
===
- Showed the reference architectures again
- Most popular use case was "Mobile service provider 5G/4G virtual RAN 
deployment and Edge Cloud B2B2X" with seven +1s on the etherpad


Deletion of project and project resources
=
- What is wanted: a delete API per service that takes a project_id and 
force deletes all resources owned by it with --dry-run component
- Challenge to work out the dependencies for the order of deletion of 
all resources in all projects. Disable project, then delete things in 
order of dependency
- Idea: turn os-purge into a REST API and each project implement a 
plugin for it


Getting operators' bug fixes upstreamed
===
- Problem: operator reports a bug and provides a solution, for example, 
pastes a diff in launchpad or otherwise describes how to fix the bug. 
How can we increase the chances of those fixes making it to gerrit?
- Concern: are there legal issues with accepting patches pasted into 
launchpad by someone who hasn't signed the ICLA?
- Possible actions: create a best practices guide tailored for operators 
and socialize it among the ops docs/meetup/midcycle group. Example: 
guidance on how to indicate you don't have time to add test coverage, 
etc when you propose a patch


THU
---

Bug triage: why not all the community?
==
- Cruft and mixing tasks with defect reports makes triage more difficult 
to manage. Example: difference between a defect reported by a user vs an 
effective TODO added by a developer. If New bugs were reliably from end 
users, would we be more likely to triage?

- Bug deputy weekly ML reporting could help
- Action: copy the generic portion of the nova bug triage wiki doc into 
the contributor guide docs. The idea/hope being that easy-to-understand 
instructions available to the wider community might increase the chances 
of people outside of the project team being capable of triaging bugs, so 
all of it doesn't fall on project teams
- Idea: should we remove the bug supervisor requirement from nova to 
allow people who haven't joined the bug team to set Status and Importance?


Current state of volume encryption
==
- Feedback: public clouds can't offer encryption because keys are stored 
in the cloud. 

[openstack-dev] [puppet] [stable] Deprecation of newton branches

[Tobias Urdin]

Hello,

We've been talking for a while about the deprecation and removal of the 
stable/newton branches.
I think it's time now that we get rid of them, we have no open patches 
and Newton is considered EOL.


Could cores get back with a quick feedback and then the stable team can 
get rid of those whenever they have time.


Best regards
Tobias

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