Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

[Blair Bethwaite]

We at Nectar are in the same boat as Mike. Our use-case is a little
bit more about geo-distributed operations though - our Cells are in
different States around the country, so the local glance-apis are
particularly important for caching popular images close to the
nova-computes. We consider these glance-apis as part of the underlying
cloud infra rather than user-facing, so I think we'd prefer not to see
them in the service-catalog returned to users either... is there going
to be a (standard) way to hide them?

On 28 April 2017 at 09:15, Mike Dorman  wrote:
> We make extensive use of the [glance]/api_servers list.  We configure that on 
> hypervisors to direct them to Glance servers which are more “local” 
> network-wise (in order to reduce network traffic across security 
> zones/firewalls/etc.)  This way nova-compute can fail over in case one of the 
> Glance servers in the list is down, without putting them behind a load 
> balancer.  We also don’t run https for these “internal” Glance calls, to save 
> the overhead when transferring images.
>
> End-user calls to Glance DO go through a real load balancer and then are 
> distributed out to the Glance servers on the backend.  From the end-user’s 
> perspective, I totally agree there should be one, and only one URL.
>
> However, we would be disappointed to see the change you’re suggesting 
> implemented.  We would lose the redundancy we get now by providing a list.  
> Or we would have to shunt all the calls through the user-facing endpoint, 
> which would generate a lot of extra traffic (in places where we don’t want 
> it) for image transfers.
>
> Thanks,
> Mike
>
>
>
> On 4/27/17, 4:02 PM, "Matt Riedemann"  wrote:
>
> On 4/27/2017 4:52 PM, Eric Fried wrote:
> > Y'all-
> >
> >   TL;DR: Does glance ever really need/use multiple endpoint URLs?
> >
> >   I'm working on bp use-service-catalog-for-endpoints[1], which intends
> > to deprecate disparate conf options in various groups, and centralize
> > acquisition of service endpoint URLs.  The idea is to introduce
> > nova.utils.get_service_url(group) -- note singular 'url'.
> >
> >   One affected conf option is [glance]api_servers[2], which currently
> > accepts a *list* of endpoint URLs.  The new API will only ever return 
> *one*.
> >
> >   Thus, as planned, this blueprint will have the side effect of
> > deprecating support for multiple glance endpoint URLs in Pike, and
> > removing said support in Queens.
> >
> >   Some have asserted that there should only ever be one endpoint URL for
> > a given service_type/interface combo[3].  I'm fine with that - it
> > simplifies things quite a bit for the bp impl - but wanted to make sure
> > there were no loudly-dissenting opinions before we get too far down this
> > path.
> >
> > [1]
> > 
> https://blueprints.launchpad.net/nova/+spec/use-service-catalog-for-endpoints
> > [2]
> > 
> https://github.com/openstack/nova/blob/7e7bdb198ed6412273e22dea72e37a6371fce8bd/nova/conf/glance.py#L27-L37
> > [3]
> > 
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-04-27.log.html#t2017-04-27T20:38:29
> >
> > Thanks,
> > Eric Fried (efried)
> > .
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> +openstack-operators
>
> --
>
> 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-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Cheers,
~Blairo

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

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

[Mike Dorman]

We make extensive use of the [glance]/api_servers list.  We configure that on 
hypervisors to direct them to Glance servers which are more “local” 
network-wise (in order to reduce network traffic across security 
zones/firewalls/etc.)  This way nova-compute can fail over in case one of the 
Glance servers in the list is down, without putting them behind a load 
balancer.  We also don’t run https for these “internal” Glance calls, to save 
the overhead when transferring images.

End-user calls to Glance DO go through a real load balancer and then are 
distributed out to the Glance servers on the backend.  From the end-user’s 
perspective, I totally agree there should be one, and only one URL.

However, we would be disappointed to see the change you’re suggesting 
implemented.  We would lose the redundancy we get now by providing a list.  Or 
we would have to shunt all the calls through the user-facing endpoint, which 
would generate a lot of extra traffic (in places where we don’t want it) for 
image transfers.

Thanks,
Mike



On 4/27/17, 4:02 PM, "Matt Riedemann"  wrote:

On 4/27/2017 4:52 PM, Eric Fried wrote:
> Y'all-
>
>   TL;DR: Does glance ever really need/use multiple endpoint URLs?
>
>   I'm working on bp use-service-catalog-for-endpoints[1], which intends
> to deprecate disparate conf options in various groups, and centralize
> acquisition of service endpoint URLs.  The idea is to introduce
> nova.utils.get_service_url(group) -- note singular 'url'.
>
>   One affected conf option is [glance]api_servers[2], which currently
> accepts a *list* of endpoint URLs.  The new API will only ever return 
*one*.
>
>   Thus, as planned, this blueprint will have the side effect of
> deprecating support for multiple glance endpoint URLs in Pike, and
> removing said support in Queens.
>
>   Some have asserted that there should only ever be one endpoint URL for
> a given service_type/interface combo[3].  I'm fine with that - it
> simplifies things quite a bit for the bp impl - but wanted to make sure
> there were no loudly-dissenting opinions before we get too far down this
> path.
>
> [1]
> 
https://blueprints.launchpad.net/nova/+spec/use-service-catalog-for-endpoints
> [2]
> 
https://github.com/openstack/nova/blob/7e7bdb198ed6412273e22dea72e37a6371fce8bd/nova/conf/glance.py#L27-L37
> [3]
> 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-04-27.log.html#t2017-04-27T20:38:29
>
> Thanks,
> Eric Fried (efried)
> .
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

+openstack-operators

-- 

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] looking for feedback on proposals to improve logging

[Nematollah Bidokhti]

Hi,

I have been working on the concept of fault management blueprint to increase 
cloud resiliency. As part of this proposal, info such as logs, KPIs, health 
checks and so on are critical since we are engaging in deep data analysis and 
machine learning.
>> 
>> To ease the data analysis process there must be consistent logs. This comes 
>> with having IDs and severity properties.
>> 
>> Cloud resiliency in general requires fast fault detection, isolation and 
>> recovery. In addition, there are applications such as NFV that is sensitive 
>> to fast fault detection and recovery. One approach is to have meaningful 
>> logs where by parsing the data we can make real time fault management 
>> decisions.
>> 
>> Similar to interrupts, I would like us to have logging hierarchy which can 
>> help an automated fault management system to take accurate and appropriate 
>> actions. The format of the logs is important since it will ease the ML 
>> analysis later in the process.
>> 
>> Thanks,
>> Nemat

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Wednesday, April 26, 2017 7:28 AM
To: openstack-operators 
Subject: [Openstack-operators] looking for feedback on proposals to improve 
logging

I am looking for some feedback on two new proposals to add IDs to log messages. 
Please see the thread on openstack-dev, and comment there or on the specs 
referenced there.

http://lists.openstack.org/pipermail/openstack-dev/2017-April/115958.html

Thanks!
Doug

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

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

[Matt Riedemann]

On 4/27/2017 4:52 PM, Eric Fried wrote:

Y'all-

TL;DR: Does glance ever really need/use multiple endpoint URLs?

I'm working on bp use-service-catalog-for-endpoints[1], which intends
to deprecate disparate conf options in various groups, and centralize
acquisition of service endpoint URLs.  The idea is to introduce
nova.utils.get_service_url(group) -- note singular 'url'.

One affected conf option is [glance]api_servers[2], which currently
accepts a *list* of endpoint URLs.  The new API will only ever return *one*.

Thus, as planned, this blueprint will have the side effect of
deprecating support for multiple glance endpoint URLs in Pike, and
removing said support in Queens.

Some have asserted that there should only ever be one endpoint URL for
a given service_type/interface combo[3].  I'm fine with that - it
simplifies things quite a bit for the bp impl - but wanted to make sure
there were no loudly-dissenting opinions before we get too far down this
path.

[1]
https://blueprints.launchpad.net/nova/+spec/use-service-catalog-for-endpoints
[2]
https://github.com/openstack/nova/blob/7e7bdb198ed6412273e22dea72e37a6371fce8bd/nova/conf/glance.py#L27-L37
[3]
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-04-27.log.html#t2017-04-27T20:38:29

Thanks,
Eric Fried (efried)
.

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



+openstack-operators

--

Thanks,

Matt

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

Re: [Openstack-operators] [scientific] Lightning talks on Scientific OpenStack

[Stig Telfer]

Hi George - 

Sorry for the slow response.  The consensus was for 8 minutes maximum.  That 
should be plenty for a lightning talk, and enables us to fit one more in.

Best wishes,
Stig


> On 27 Apr 2017, at 20:29, George Mihaiescu  wrote:
> 
> Hi Stig, it will be 10 minutes sessions like in Barcelona?
> 
> Thanks,
> George 
> 
>> On Apr 26, 2017, at 03:31, Stig Telfer  wrote:
>> 
>> Hi All - 
>> 
>> We have planned a session of lightning talks at the Boston summit to discuss 
>> topics specific for OpenStack and research computing applications.  This was 
>> a great success at Barcelona and generated some stimulating discussion.  We 
>> are also hoping for a small prize for the best talk of the session!
>> 
>> This is the event:
>> https://www.openstack.org/summit/boston-2017/summit-schedule/events/18676
>> 
>> If you’d like to propose a talk, please add a title and your name here:
>> https://etherpad.openstack.org/p/Scientific-WG-boston
>> 
>> Everyone is welcome.
>> 
>> Cheers,
>> Stig
>> 
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


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

Re: [Openstack-operators] [scientific] Lightning talks on Scientific OpenStack

[George Mihaiescu]

Hi Stig, it will be 10 minutes sessions like in Barcelona?

Thanks,
George 

> On Apr 26, 2017, at 03:31, Stig Telfer  wrote:
> 
> Hi All - 
> 
> We have planned a session of lightning talks at the Boston summit to discuss 
> topics specific for OpenStack and research computing applications.  This was 
> a great success at Barcelona and generated some stimulating discussion.  We 
> are also hoping for a small prize for the best talk of the session!
> 
> This is the event:
> https://www.openstack.org/summit/boston-2017/summit-schedule/events/18676
> 
> If you’d like to propose a talk, please add a title and your name here:
> https://etherpad.openstack.org/p/Scientific-WG-boston
> 
> Everyone is welcome.
> 
> Cheers,
> Stig
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [Openstack-operators] [puppet] Deprecating Postgresql support

[Matt Riedemann]

On 4/27/2017 8:54 AM, Emilien Macchi wrote:

[adding mailing-lists again]

On Thu, Apr 27, 2017 at 9:31 AM, Benedikt Trefzer  wrote:

Hi Emilien

On 27.04.2017 13:38, Emilien Macchi wrote:

Greetings,

We didn't see anyone using Postgresql when deploying Puppet OpenStack:
- no feedback on ML or IRC
- no bug report in Launchpad


Because it just works !
We use it.


Good to know. That's the kind of information that we like to know
because we're blinding doing stuff for users that we don't know much.


Postgresql support (or call it how you want) is also removed upstream
in OpenStack.

Do you have any reference for this ?
I could not find anything  about this !


We will deprecate the class that used to deploy Postgresql in Pike and
remove the code in Queens.

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

Any feedback is very welcome before we do it.

My Feedback: so sad, but are there any chances to change ?


We hate when our users are sad. No worries, we won't break you.
Right now, the immediate concern is that puppetlabs-postgresql 4.9.0
(latest tag) doesn't work with puppetlabs-concat 4.0.0. We have to pin
it to 3.0.0 in Puppet OpenStack CI and we don't like pins.
If you or someone from your team could fix puppetlabs-postgresql, we
could unpin and be happy again.

On my side, I'm fine to let puppet code that manage postgresql
databases,users,permissions. It's not something 1) breaks often 2)
change often, so the cost of maintenance is imho low. But I'll let the
decision to other folks in our group.

Thanks for this feedback!
Please keep giving more of it, on public channels.


Greetings

Benedikt







Support for postgresql has not been dropped in OpenStack. Deprecating it 
has been proposed:


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

There is also a session at the upcoming Forum in Boston about this:

https://www.openstack.org/summit/boston-2017/summit-schedule/events/18730/deprecation-of-postgresql

--

Thanks,

Matt

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

Re: [Openstack-operators] [puppet] Deprecating Postgresql support

[Emilien Macchi]

On Thu, Apr 27, 2017 at 7:38 AM, Emilien Macchi  wrote:
> Greetings,
>
> We didn't see anyone using Postgresql when deploying Puppet OpenStack:
> - no feedback on ML or IRC
> - no bug report in Launchpad
>
> Postgresql support (or call it how you want) is also removed upstream
> in OpenStack.

I was wrong, the discussion is still ongoing and there is a session
about that in Boston that you might want to participate if you're
deploying PG.

> We will deprecate the class that used to deploy Postgresql in Pike and
> remove the code in Queens.
>
> https://review.openstack.org/#/c/460249/
>
> Any feedback is very welcome before we do it.

We got some feedback from our users who still use PG, so for now,
we're not deprecating anything.

> Thanks,
> --
> Emilien Macchi



-- 
Emilien Macchi

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

[Openstack-operators] Last Opportunity: OpenStack Days East 2017

[Haisam Ido]

Dear Potential Sponsors of OpenStack Days East 2017:


This is the *last* Opportunity to Engage and Educate at OpenStack Days East
 as a Sponsor for 2017!

The all *volunteer* organizing committee has been working hard to create a
robust agenda for OpenStack Days East , an
event scheduled for Fall 2017 in Washington, DC.  But we *can’t* move
forward without Headline and Event sponsors to help secure the venue!  This
annual gathering of OpenStack enthusiasts, users and operators, is an ideal
opportunity to educate and engage the OpenStack community.

We invite you to review the sponsorship levels
,
send us a completed the sponsorship agreement form

indicating which level best suits your company! *But hurry, we have
fast-approaching deadlines (this week to receive funding) and a limited
sponsorship opportunities!*

Please feel free to contact Haisam Ido 
at or Suzie Grieco  with any questions!


Best Regards,

OpenStack Days East Planning Committee


haisam@openstackdayseast.com, Organizer

hong@openstackdayseast.com, Organizer

shilla.sa...@openstackdayseast.com, Organizer

james.ge...@openstackdayseast.com, Organizer

trevor.low...@openstackdayseast.com, Organizer

kirk.kalvar@kal.technology, Organizer

suzie.gri...@openstackdayseast.com, Organizer
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [LDT] Scheduling of 'plan the week' at the summit

[Tim Bell]

The Large Deployment Team meeting for ‘Plan the Week’ 
(https://www.openstack.org/summit/boston-2017/summit-schedule/events/18404/large-deployment-team-planning-the-week)
 seems to be on Wednesday at 11h00 and the Recapping the week is the next slot 
at 11h50 
(https://www.openstack.org/summit/boston-2017/summit-schedule/events/18406/large-deployment-team-recapping-the-week)

Is this intended to have the two sessions so close together?

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

Re: [Openstack-operators] [Openstack] [Openstack-ansible] openstack ansible HA solution

[Logan V.]

Hello,

Yes openstack-ansible does support deploying keepalived along with
haproxy. The keepalived role is run just before the haproxy role in
this playbook: 
https://github.com/openstack/openstack-ansible/blob/master/playbooks/haproxy-install.yml#L27-L31

You can see an example keepalived configuration in the prod config
example of the OSA deployment guide:
https://docs.openstack.org/project-deploy-guide/openstack-ansible/draft/app-config-prod.html#user-variables

On Wed, Apr 26, 2017 at 3:32 AM, Liyuenan (Maxwell Li)
 wrote:
> Hi, all
>
>
>
> I have some questions about OSA project.
>
>
>
> 1.   OSA can install haproxy, but I can not found any other HA solution
> in openstack-ansible-haproxy_server, like keepalived or pacemarker. So how
> to making HAproxy high-available?
>
> 2.   Could OSA support compute node high available? If my compute node
> down, could the instance on this node move to other nodes?
>
>
>
> Thank you!
>
>
>
> Best Regards!
>
> Maxwell Li
>
> maxwelli.com
>
>
>
>
> ___
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [puppet] Deprecating Postgresql support

[Emilien Macchi]

[adding mailing-lists again]

On Thu, Apr 27, 2017 at 9:31 AM, Benedikt Trefzer  wrote:
> Hi Emilien
>
> On 27.04.2017 13:38, Emilien Macchi wrote:
>> Greetings,
>>
>> We didn't see anyone using Postgresql when deploying Puppet OpenStack:
>> - no feedback on ML or IRC
>> - no bug report in Launchpad
>
> Because it just works !
> We use it.

Good to know. That's the kind of information that we like to know
because we're blinding doing stuff for users that we don't know much.

>> Postgresql support (or call it how you want) is also removed upstream
>> in OpenStack.
> Do you have any reference for this ?
> I could not find anything  about this !
>
>> We will deprecate the class that used to deploy Postgresql in Pike and
>> remove the code in Queens.
>>
>> https://review.openstack.org/#/c/460249/
>>
>> Any feedback is very welcome before we do it.
> My Feedback: so sad, but are there any chances to change ?

We hate when our users are sad. No worries, we won't break you.
Right now, the immediate concern is that puppetlabs-postgresql 4.9.0
(latest tag) doesn't work with puppetlabs-concat 4.0.0. We have to pin
it to 3.0.0 in Puppet OpenStack CI and we don't like pins.
If you or someone from your team could fix puppetlabs-postgresql, we
could unpin and be happy again.

On my side, I'm fine to let puppet code that manage postgresql
databases,users,permissions. It's not something 1) breaks often 2)
change often, so the cost of maintenance is imho low. But I'll let the
decision to other folks in our group.

Thanks for this feedback!
Please keep giving more of it, on public channels.

> Greetings
>
> Benedikt
>



-- 
Emilien Macchi

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

[Openstack-operators] [puppet] Deprecating Postgresql support

[Emilien Macchi]

Greetings,

We didn't see anyone using Postgresql when deploying Puppet OpenStack:
- no feedback on ML or IRC
- no bug report in Launchpad

Postgresql support (or call it how you want) is also removed upstream
in OpenStack.
We will deprecate the class that used to deploy Postgresql in Pike and
remove the code in Queens.

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

Any feedback is very welcome before we do it.

Thanks,
-- 
Emilien Macchi

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