Re: [Openstack-operators] Request for [ideas][help wanted] with OpenStack tooling

[Pablo Iranzo Gómez]

Hi all,

Apart of some updates above what Robin mentioned in December (Now: 170+ 
plugins, ansible
support, checks across different systems, web interface, json output,
pip package, container, etc) we're starting to add support for Debian-based 
distributions.

Would it be possible for you running OSP on Debian (or even regular
Debian/Ubuntu/etc) installations to contribute a 'sosreport' (yes you
can install sosreport tool on Debian*)  ?

If so, would you mind attaching them at
https://www.dropbox.com/request/8LGneF9i9nc9RB6aqXge

Or reply to us with the url for us to download?

Thanks a lot!
Pablo

PD: In case you're interested we've #citellus channel on freenode and
mailing list at citellus-...@redhat.com

+++ Robin Cernin [01/12/17 15:39 +1000]:

Hello,

This is my second time reaching out to this ML. We are all having same
ultimate goal guys. Fixing the problems as soon as possible.

Back then in June (SUBJ:OpenStack logs Health Validator) we had rough
version, now we are reaching 6 months and we have done 75 scripts
(currently) checking things not only in OpenStack deployment.

https://github.com/zerodayz/citellus

What I am looking for from you is if you would be please so kind and take a
look, create issues what you think would be the best to bring this tool to
a higher level.

75 scripts so far having output to JSON planning on adding Web front-end.
From last OpenStack Australia Group Meetup here in Brisbane I got some
feedback on adding configuration options so one doesn't have to re-type all
the things and instead use config file.

We have all documentation you can imagine including templates:

How to Contribute:
https://github.com/zerodayz/citellus/blob/master/CONTRIBUTING.md
Templates: https://github.com/zerodayz/citellus/tree/master/doc/templates
Writing Tests: https://github.com/zerodayz/citellus/blob/master/TESTING.md
Presentation in reveal-md:
https://github.com/zerodayz/citellus/blob/master/doc/presentation-revealmd.md
How to Review code:
https://github.com/zerodayz/citellus/blob/master/REVIEWER.md

We are now mainly focused on RPM distribution but we could add multiple
distros, we are also discussing the possible way of integrating this with
Ansible and it's playbook so we could use them too.

if you are interested please create issue, code(see How to Contribute),
join discussion in github.

Thank you!
Robin Černín


--

Pablo Iranzo Gómez (pablo.ira...@redhat.com)  GnuPG: 0x5BD8E1E4
Senior Software Maintenance Engineer - OpenStack   iranzo @ IRC
RHC{A,SS,DS,VA,E,SA,SP,AOSP}, JBCAA#110-215-852RHCA Level V


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

[Openstack-operators] [forum] We want your session ideas for the Vancouver Forum!

[Melvin Hillsman]

Hey everyone,

Please take time to put ideas for sessions at the forum in the TC and/or UC
catch-all etherpads or any of the others that are appropriate:

https://wiki.openstack.org/wiki/Forum/Vancouver2018

We really want to get as many session ideas as possible so that the
committee has too many to choose from :)

Here is an idea of the types of sessions to think about proposing:

*Project-specific sessions*

Where developers can ask users specific questions about their experience,
users can provide feedback from the last release and cross-community
collaboration on the priorities and 'blue sky' ideas for the next release
can occur.
*Strategic, whole-of-community discussions*

To think about the big picture, including beyond just one release cycle and
new technologies
*Cross-project sessions*

In a similar vein to what has happened at past design summits, but with
increased emphasis on issues that are of relevant to all areas of the
community


If you have organized any events in the past year you probably have heard
of or been in some sessions that are perfect for the Forum.

-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [self-healing] Dublin PTG summary, and request for feedback

[Adam Spiers]

Hi all,

I just posted a summary of the Self-healing SIG session at the Dublin
PTG:

  http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000317.html

If you are interested in the topic of self-healing within OpenStack,
you are warmly invited to subscribe to the openstack-sigs mailing
list:

  http://lists.openstack.org/pipermail/openstack-sigs/

and/or join the #openstack-self-healing channel on Freenode IRC.

We are actively gathering feedback to help steer the SIG's focus in
the right direction, so all thoughts are very welcome, especially from
operators, since the primary goal of the SIG is to make life easier
for operators.

I have also just created an etherpad for brainstorming topics for the
Forum in Vancouver:

  https://etherpad.openstack.org/p/YVR-self-healing-brainstorming

Feel free to put braindumps in there :-)

Thanks!
Adam

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

Re: [Openstack-operators] How are you handling billing/chargeback?

[Tim Bell]

We’re using a combination of cASO (https://caso.readthedocs.io/en/stable/) and 
some low level libvirt fabric monitoring. The showback accounting reports are 
generated with merging with other compute/storage usage across various systems 
(HTCondor, SLURM, ...)

It would seem that those who needed solutions in the past found they had to do 
them themselves. It would be interesting if there are references of usage 
data/accounting/chargeback at scale with the current project set but doing the 
re-evaluation would be an effort which would need to be balanced versus just 
keeping the local solution working.

Tim

-Original Message-
From: Lars Kellogg-Stedman 
Date: Wednesday, 14 March 2018 at 17:15
To: openstack-operators 
Subject: Re: [Openstack-operators] How are you handling billing/chargeback?

On Mon, Mar 12, 2018 at 03:21:13PM -0400, Lars Kellogg-Stedman wrote:
> I'm curious what folks out there are using for chargeback/billing in
> your OpenStack environment.

So far it looks like everyone is using a homegrown solution.  Is
anyone using an existing product/project?

-- 
Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
http://blog.oddbit.com/|

___
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] How are you handling billing/chargeback?

[Tobias Urdin]

We are using the billing engine part of the commercial software provided
by Atomia [1].

Using ceilometer as of now, but they just recently added support for
Gnocchi which we are gonna use for our newer setups.


[1] https://www.atomia.com


On 03/14/2018 05:13 PM, Lars Kellogg-Stedman wrote:
> On Mon, Mar 12, 2018 at 03:21:13PM -0400, Lars Kellogg-Stedman wrote:
>> I'm curious what folks out there are using for chargeback/billing in
>> your OpenStack environment.
> So far it looks like everyone is using a homegrown solution.  Is
> anyone using an existing product/project?
>


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

Re: [Openstack-operators] How are you handling billing/chargeback?

[Lars Kellogg-Stedman]

On Mon, Mar 12, 2018 at 03:21:13PM -0400, Lars Kellogg-Stedman wrote:
> I'm curious what folks out there are using for chargeback/billing in
> your OpenStack environment.

So far it looks like everyone is using a homegrown solution.  Is
anyone using an existing product/project?

-- 
Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
http://blog.oddbit.com/|

___
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] about rebuild instance booted from volume

[Tomáš Vondra]

Hi!
I say delete! Delete them all!
Really, it's called delete_on_termination and should be ignored on Rebuild.
We have a VPS service implemented on top of OpenStack and do throw the old 
contents away on Rebuild. When the user has the Backup service paid, they can 
restore a snapshot. Backup is implemented as volume snapshot, then clone 
volume, then upload to image (glance is on a different disk array).

I also sometimes multi-attach a volume manually to a service node and just dd 
an image onto it. If it was to be implemented this way, then there would be no 
deleting a volume with delete_on_termination, just overwriting. But the effect 
is the same.

IMHO you can have snapshots of volumes that have been deleted. Just some 
backends like our 3PAR don't allow it, but it's not disallowed in the API 
contract.
Tomas from Homeatcloud

-Original Message-
From: Saverio Proto [mailto:ziopr...@gmail.com] 
Sent: Wednesday, March 14, 2018 3:19 PM
To: Tim Bell; Matt Riedemann
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [openstack-dev] [nova] about rebuild 
instance booted from volume

My idea is that if delete_on_termination flag is set to False the Volume should 
never be deleted by Nova.

my 2 cents

Saverio

2018-03-14 15:10 GMT+01:00 Tim Bell :
> Matt,
>
> To add another scenario and make things even more difficult (sorry (), if the 
> original volume has snapshots, I don't think you can delete it.
>
> Tim
>
>
> -Original Message-
> From: Matt Riedemann 
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" 
> Date: Wednesday, 14 March 2018 at 14:55
> To: "openstack-...@lists.openstack.org" 
> , openstack-operators 
> 
> Subject: Re: [openstack-dev] [nova] about rebuild instance booted from 
> volume
>
> On 3/14/2018 3:42 AM, 李杰 wrote:
> >
> >  This is the spec about  rebuild a instance booted from
> > volume.In the spec,there is a
> >question about if we should delete the old root_volume.Anyone who
> > is interested in
> >booted from volume can help to review this. Any suggestion is
> > welcome.Thank you!
> >The link is here.
> >Re:the rebuild spec:https://review.openstack.org/#/c/532407/
>
> Copying the operators list and giving some more context.
>
> This spec is proposing to add support for rebuild with a new image for
> volume-backed servers, which today is just a 400 failure in the API
> since the compute doesn't support that scenario.
>
> With the proposed solution, the backing root volume would be deleted and
> a new volume would be created from the new image, similar to how boot
> from volume works.
>
> The question raised in the spec is whether or not nova should delete the
> root volume even if its delete_on_termination flag is set to False. The
> semantics get a bit weird here since that flag was not meant for this
> scenario, it's meant to be used when deleting the server to which the
> volume is attached. Rebuilding a server is not deleting it, but we would
> need to replace the root volume, so what do we do with the volume we're
> replacing?
>
> Do we say that delete_on_termination only applies to deleting a server
> and not rebuild and therefore nova can delete the root volume during a
> rebuild?
>
> If we don't delete the volume during rebuild, we could end up leaving a
> lot of volumes lying around that the user then has to clean up,
> otherwise they'll eventually go over quota.
>
> We need user (and operator) feedback on this issue and what they would
> expect to happen.
>
> --
>
> 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-operator
> s

___
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] about rebuild instance booted from volume

[Matthew Booth]

On 14 March 2018 at 13:46, Matt Riedemann  wrote:

> On 3/14/2018 3:42 AM, 李杰 wrote:
>
>>
>>  This is the spec about  rebuild a instance booted from
>> volume.In the spec,there is a
>>question about if we should delete the old root_volume.Anyone who
>> is interested in
>>booted from volume can help to review this. Any suggestion is
>> welcome.Thank you!
>>The link is here.
>>Re:the rebuild spec:https://review.openstack.org/#/c/532407/
>>
>
> Copying the operators list and giving some more context.
>
> This spec is proposing to add support for rebuild with a new image for
> volume-backed servers, which today is just a 400 failure in the API since
> the compute doesn't support that scenario.
>
> With the proposed solution, the backing root volume would be deleted and a
> new volume would be created from the new image, similar to how boot from
> volume works.
>
> The question raised in the spec is whether or not nova should delete the
> root volume even if its delete_on_termination flag is set to False. The
> semantics get a bit weird here since that flag was not meant for this
> scenario, it's meant to be used when deleting the server to which the
> volume is attached. Rebuilding a server is not deleting it, but we would
> need to replace the root volume, so what do we do with the volume we're
> replacing?
>
> Do we say that delete_on_termination only applies to deleting a server and
> not rebuild and therefore nova can delete the root volume during a rebuild?
>
> If we don't delete the volume during rebuild, we could end up leaving a
> lot of volumes lying around that the user then has to clean up, otherwise
> they'll eventually go over quota.
>
> We need user (and operator) feedback on this issue and what they would
> expect to happen.
>

My 2c was to overwrite, not delete the volume[1]. I believe this preserves
both sets of semantics: the server is rebuilt, and the volume is not
deleted. The user will still lose their data, of course, but that's implied
by the rebuild they explicitly requested. The volume id will remain the
same.

[1] I suspect this would require new functionality in cinder to
re-initialize from image.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)
___
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] about rebuild instance booted from volume

[Blair Bethwaite]

Please do not default to deleting it, otherwise someone will eventually be
back here asking why an irate user has just lost data. The better scenario
is that the rebuild will fail (early - before impact to the running
instance) with a quota error.

Cheers,

On Thu., 15 Mar. 2018, 00:46 Matt Riedemann,  wrote:

> On 3/14/2018 3:42 AM, 李杰 wrote:
> >
> >  This is the spec about  rebuild a instance booted from
> > volume.In the spec,there is a
> >question about if we should delete the old root_volume.Anyone who
> > is interested in
> >booted from volume can help to review this. Any suggestion is
> > welcome.Thank you!
> >The link is here.
> >Re:the rebuild spec:https://review.openstack.org/#/c/532407/
>
> Copying the operators list and giving some more context.
>
> This spec is proposing to add support for rebuild with a new image for
> volume-backed servers, which today is just a 400 failure in the API
> since the compute doesn't support that scenario.
>
> With the proposed solution, the backing root volume would be deleted and
> a new volume would be created from the new image, similar to how boot
> from volume works.
>
> The question raised in the spec is whether or not nova should delete the
> root volume even if its delete_on_termination flag is set to False. The
> semantics get a bit weird here since that flag was not meant for this
> scenario, it's meant to be used when deleting the server to which the
> volume is attached. Rebuilding a server is not deleting it, but we would
> need to replace the root volume, so what do we do with the volume we're
> replacing?
>
> Do we say that delete_on_termination only applies to deleting a server
> and not rebuild and therefore nova can delete the root volume during a
> rebuild?
>
> If we don't delete the volume during rebuild, we could end up leaving a
> lot of volumes lying around that the user then has to clean up,
> otherwise they'll eventually go over quota.
>
> We need user (and operator) feedback on this issue and what they would
> expect to happen.
>
> --
>
> 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] [openstack-dev] [nova] about rebuild instance booted from volume

[Saverio Proto]

My idea is that if delete_on_termination flag is set to False the
Volume should never be deleted by Nova.

my 2 cents

Saverio

2018-03-14 15:10 GMT+01:00 Tim Bell :
> Matt,
>
> To add another scenario and make things even more difficult (sorry (), if the 
> original volume has snapshots, I don't think you can delete it.
>
> Tim
>
>
> -Original Message-
> From: Matt Riedemann 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: Wednesday, 14 March 2018 at 14:55
> To: "openstack-...@lists.openstack.org" , 
> openstack-operators 
> Subject: Re: [openstack-dev] [nova] about rebuild instance booted from volume
>
> On 3/14/2018 3:42 AM, 李杰 wrote:
> >
> >  This is the spec about  rebuild a instance booted from
> > volume.In the spec,there is a
> >question about if we should delete the old root_volume.Anyone who
> > is interested in
> >booted from volume can help to review this. Any suggestion is
> > welcome.Thank you!
> >The link is here.
> >Re:the rebuild spec:https://review.openstack.org/#/c/532407/
>
> Copying the operators list and giving some more context.
>
> This spec is proposing to add support for rebuild with a new image for
> volume-backed servers, which today is just a 400 failure in the API
> since the compute doesn't support that scenario.
>
> With the proposed solution, the backing root volume would be deleted and
> a new volume would be created from the new image, similar to how boot
> from volume works.
>
> The question raised in the spec is whether or not nova should delete the
> root volume even if its delete_on_termination flag is set to False. The
> semantics get a bit weird here since that flag was not meant for this
> scenario, it's meant to be used when deleting the server to which the
> volume is attached. Rebuilding a server is not deleting it, but we would
> need to replace the root volume, so what do we do with the volume we're
> replacing?
>
> Do we say that delete_on_termination only applies to deleting a server
> and not rebuild and therefore nova can delete the root volume during a
> rebuild?
>
> If we don't delete the volume during rebuild, we could end up leaving a
> lot of volumes lying around that the user then has to clean up,
> otherwise they'll eventually go over quota.
>
> We need user (and operator) feedback on this issue and what they would
> expect to happen.
>
> --
>
> 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

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

Re: [Openstack-operators] How are you handling billing/chargeback?

[Nick Jones]

On 13/03, Simon Leinen wrote:

Lars Kellogg-Stedman writes:

I'm curious what folks out there are using for chargeback/billing in
your OpenStack environment.


We use a homegrown billing system that periodically samples utilization
of billable resources.


We had something similar at DataCentred - a homegrown (Rails-based)
application, but one which periodically polled Ceilometer for
utilisation information and subsequently performed a bunch of sanity
checks.  It was open-sourced for posterity here:

https://github.com/seanhandley/stronghold

This was used to generate billing information with integration into
Salesforce.

--

-Nick

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

Re: [Openstack-operators] Stable Branch EOL and "Extended Maintenance" Resolution

[Melvin Hillsman]

Hi everyone,

I believe this resolution is getting close to being passed and so I highly
suggest anyone interested provide any feedback they have
good/bad/indifferent -
https://review.openstack.org/#/c/548916/3/resolutions/20180301-stable-branch-eol.rst

On Thu, Mar 8, 2018 at 7:42 AM, Anne Bertucio  wrote:

> Hi all,
>
> Given our conversations this morning at the Ops Midcycle about Extended
> Maintenance, particularly how projects individually deciding stable
> maintenance policies would affect operators, I wanted to pop this to the
> top of your inbox again. The thread is actively moving, so it’d be good to
> get your operator input in there: https://review.openstack.org/#/c/548916/
>
>
> Anne Bertucio
> OpenStack Foundation
> a...@openstack.org | irc: annabelleB
>
>
>
>
>
> On Mar 7, 2018, at 1:16 PM, Chris Morgan  wrote:
>
> Thanks for pointing this one out!
>
> Chris
>
> On Tue, Mar 6, 2018 at 9:53 PM, Melvin Hillsman 
> wrote:
>
>> Hi everyone,
>>
>> If you are interested in the items in the subject please be sure to take
>> time to review and comment on the following patch -
>> https://review.openstack.org/#/c/548916/
>>
>> --
>> Kind regards,
>>
>> Melvin Hillsman
>> mrhills...@gmail.com
>> mobile: (832) 264-2646
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
> Chris Morgan 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>


-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
___
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] about rebuild instance booted from volume

[Tim Bell]

Matt,

To add another scenario and make things even more difficult (sorry (), if the 
original volume has snapshots, I don't think you can delete it.

Tim


-Original Message-
From: Matt Riedemann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 14 March 2018 at 14:55
To: "openstack-...@lists.openstack.org" , 
openstack-operators 
Subject: Re: [openstack-dev] [nova] about rebuild instance booted from volume

On 3/14/2018 3:42 AM, 李杰 wrote:
> 
>  This is the spec about  rebuild a instance booted from 
> volume.In the spec,there is a
>question about if we should delete the old root_volume.Anyone who 
> is interested in
>booted from volume can help to review this. Any suggestion is 
> welcome.Thank you!
>The link is here.
>Re:the rebuild spec:https://review.openstack.org/#/c/532407/

Copying the operators list and giving some more context.

This spec is proposing to add support for rebuild with a new image for 
volume-backed servers, which today is just a 400 failure in the API 
since the compute doesn't support that scenario.

With the proposed solution, the backing root volume would be deleted and 
a new volume would be created from the new image, similar to how boot 
from volume works.

The question raised in the spec is whether or not nova should delete the 
root volume even if its delete_on_termination flag is set to False. The 
semantics get a bit weird here since that flag was not meant for this 
scenario, it's meant to be used when deleting the server to which the 
volume is attached. Rebuilding a server is not deleting it, but we would 
need to replace the root volume, so what do we do with the volume we're 
replacing?

Do we say that delete_on_termination only applies to deleting a server 
and not rebuild and therefore nova can delete the root volume during a 
rebuild?

If we don't delete the volume during rebuild, we could end up leaving a 
lot of volumes lying around that the user then has to clean up, 
otherwise they'll eventually go over quota.

We need user (and operator) feedback on this issue and what they would 
expect to happen.

-- 

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] [openstack-dev] [nova] about rebuild instance booted from volume

[Matt Riedemann]

On 3/14/2018 3:42 AM, 李杰 wrote:


             This is the spec about  rebuild a instance booted from 
volume.In the spec,there is a
       question about if we should delete the old root_volume.Anyone who 
is interested in
       booted from volume can help to review this. Any suggestion is 
welcome.Thank you!

       The link is here.
       Re:the rebuild spec:https://review.openstack.org/#/c/532407/


Copying the operators list and giving some more context.

This spec is proposing to add support for rebuild with a new image for 
volume-backed servers, which today is just a 400 failure in the API 
since the compute doesn't support that scenario.


With the proposed solution, the backing root volume would be deleted and 
a new volume would be created from the new image, similar to how boot 
from volume works.


The question raised in the spec is whether or not nova should delete the 
root volume even if its delete_on_termination flag is set to False. The 
semantics get a bit weird here since that flag was not meant for this 
scenario, it's meant to be used when deleting the server to which the 
volume is attached. Rebuilding a server is not deleting it, but we would 
need to replace the root volume, so what do we do with the volume we're 
replacing?


Do we say that delete_on_termination only applies to deleting a server 
and not rebuild and therefore nova can delete the root volume during a 
rebuild?


If we don't delete the volume during rebuild, we could end up leaving a 
lot of volumes lying around that the user then has to clean up, 
otherwise they'll eventually go over quota.


We need user (and operator) feedback on this issue and what they would 
expect to happen.


--

Thanks,

Matt

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

Re: [Openstack-operators] How are you handling billing/chargeback?

[Lars Kellogg-Stedman]

On Tue, Mar 13, 2018 at 07:21:39PM -0400, Mike Lowe wrote:
> Ceilometer (now panko) vm exists events coerced to look like jobs from a HPC 
> batch system.

Interesting. And are you feeding that into an off-the-shelf HPC
accounting system, or did you have an existing locally-developed
system in place?

-- 
Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
http://blog.oddbit.com/|

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

Re: [Openstack-operators] [openstack-dev] Poll: S Release Naming

[Sławomir Kapłoński]

Indeed. I now tried from different IP address and I was able to vote. Thx a lot 
for help.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Thierry Carrez  w dniu 
> 14.03.2018, o godz. 10:05:
> 
> Jens Harbott wrote:
>> 2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński :
>>> Hi,
>>> 
>>> Are You sure this link is good? I just tried it and I got info that 
>>> "Already voted" which isn't true in fact :)
>> 
>> Comparing with previous polls, these should be personalized links that
>> need to be sent out to each voter individually, so I agree that this
>> looks like a mistake.
> 
> We crashed CIVS for the last naming with a private poll sent to all the
> Foundation membership, so the TC decided to use public (open) polling
> this time around. Anyone with the link can vote, nothing was sent to
> each of the voters individually.
> 
> The "Already voted" error might be due to CIVS limiting public polling
> to one entry per IP, and a colleague of yours already voted... Maybe try
> from another IP address ?
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [Openstack-operators] [openstack-dev] Poll: S Release Naming

[Thierry Carrez]

Jens Harbott wrote:
> 2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński :
>> Hi,
>>
>> Are You sure this link is good? I just tried it and I got info that "Already 
>> voted" which isn't true in fact :)
> 
> Comparing with previous polls, these should be personalized links that
> need to be sent out to each voter individually, so I agree that this
> looks like a mistake.

We crashed CIVS for the last naming with a private poll sent to all the
Foundation membership, so the TC decided to use public (open) polling
this time around. Anyone with the link can vote, nothing was sent to
each of the voters individually.

The "Already voted" error might be due to CIVS limiting public polling
to one entry per IP, and a colleague of yours already voted... Maybe try
from another IP address ?

-- 
Thierry Carrez (ttx)

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

Re: [Openstack-operators] [openstack-dev] Poll: S Release Naming

[Jens Harbott]

2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński :
> Hi,
>
> Are You sure this link is good? I just tried it and I got info that "Already 
> voted" which isn't true in fact :)

Comparing with previous polls, these should be personalized links that
need to be sent out to each voter individually, so I agree that this
looks like a mistake.

>> Wiadomość napisana przez Paul Belanger  w dniu 
>> 14.03.2018, o godz. 00:58:
>>
>> Greetings all,
>>
>> It is time again to cast your vote for the naming of the S Release. This time
>> is little different as we've decided to use a public polling option over per
>> user private URLs for voting. This means, everybody should proceed to use the
>> following URL to cast their vote:
>>
>>  
>> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3
>>
>> Because this is a public poll, results will currently be only viewable by 
>> myself
>> until the poll closes. Once closed, I'll post the URL making the results
>> viewable to everybody. This was done to avoid everybody seeing the results 
>> while
>> the public poll is running.
>>
>> The poll will officially end on 2018-03-21 23:59:59[1], and results will be
>> posted shortly after.
>>
>> [1] 
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
>> ---
>>
>> According to the Release Naming Process, this poll is to determine the
>> community preferences for the name of the R release of OpenStack. It is
>> possible that the top choice is not viable for legal reasons, so the second 
>> or
>> later community preference could wind up being the name.
>>
>> Release Name Criteria
>>
>> Each release name must start with the letter of the ISO basic Latin alphabet
>> following the initial letter of the previous release, starting with the
>> initial release of "Austin". After "Z", the next name should start with
>> "A" again.
>>
>> The name must be composed only of the 26 characters of the ISO basic Latin
>> alphabet. Names which can be transliterated into this character set are also
>> acceptable.
>>
>> The name must refer to the physical or human geography of the region
>> encompassing the location of the OpenStack design summit for the
>> corresponding release. The exact boundaries of the geographic region under
>> consideration must be declared before the opening of nominations, as part of
>> the initiation of the selection process.
>>
>> The name must be a single word with a maximum of 10 characters. Words that
>> describe the feature should not be included, so "Foo City" or "Foo Peak"
>> would both be eligible as "Foo".
>>
>> Names which do not meet these criteria but otherwise sound really cool
>> should be added to a separate section of the wiki page and the TC may make
>> an exception for one or more of them to be considered in the Condorcet poll.
>> The naming official is responsible for presenting the list of exceptional
>> names for consideration to the TC before the poll opens.
>>
>> Exact Geographic Region
>>
>> The Geographic Region from where names for the S release will come is Berlin
>>
>> Proposed Names
>>
>> Spree (a river that flows through the Saxony, Brandenburg and Berlin states 
>> of
>>   Germany)
>>
>> SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)
>>
>> Spandau (One of the twelve boroughs of Berlin)
>>
>> Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
>>   abbreviated as )
>>
>> Steglitz (a locality in the South Western part of the city)
>>
>> Springer (Berlin is headquarters of Axel Springer publishing house)
>>
>> Staaken (a locality within the Spandau borough)
>>
>> Schoenholz (A zone in the Niederschönhausen district of Berlin)
>>
>> Shellhaus (A famous office building)
>>
>> Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)
>>
>> Schiller (A park in the Mitte borough)
>>
>> Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
>>   (The adjective form, Saatwinkler is also a really cool bridge but
>>   that form is too long)
>>
>> Sonne (Sonnenallee is the name of a large street in Berlin crossing the 
>> former
>>   wall, also translates as "sun")
>>
>> Savigny (Common place in City-West)
>>
>> Soorstreet (Street in Berlin restrict Charlottenburg)
>>
>> Solar (Skybar in Berlin)
>>
>> See (Seestraße or "See Street" in Berlin)
>>
>> Thanks,
>> Paul
>>
>> __
>> OpenStack Development Mailing 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-operators] [openstack-dev] Poll: S Release Naming

[Sławomir Kapłoński]

Hi,

Are You sure this link is good? I just tried it and I got info that "Already 
voted" which isn't true in fact :)

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Paul Belanger  w dniu 
> 14.03.2018, o godz. 00:58:
> 
> Greetings all,
> 
> It is time again to cast your vote for the naming of the S Release. This time
> is little different as we've decided to use a public polling option over per
> user private URLs for voting. This means, everybody should proceed to use the
> following URL to cast their vote:
> 
>  
> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3
> 
> Because this is a public poll, results will currently be only viewable by 
> myself
> until the poll closes. Once closed, I'll post the URL making the results
> viewable to everybody. This was done to avoid everybody seeing the results 
> while
> the public poll is running.
> 
> The poll will officially end on 2018-03-21 23:59:59[1], and results will be
> posted shortly after.
> 
> [1] 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
> ---
> 
> According to the Release Naming Process, this poll is to determine the
> community preferences for the name of the R release of OpenStack. It is
> possible that the top choice is not viable for legal reasons, so the second or
> later community preference could wind up being the name.
> 
> Release Name Criteria
> 
> Each release name must start with the letter of the ISO basic Latin alphabet
> following the initial letter of the previous release, starting with the
> initial release of "Austin". After "Z", the next name should start with
> "A" again.
> 
> The name must be composed only of the 26 characters of the ISO basic Latin
> alphabet. Names which can be transliterated into this character set are also
> acceptable.
> 
> The name must refer to the physical or human geography of the region
> encompassing the location of the OpenStack design summit for the
> corresponding release. The exact boundaries of the geographic region under
> consideration must be declared before the opening of nominations, as part of
> the initiation of the selection process.
> 
> The name must be a single word with a maximum of 10 characters. Words that
> describe the feature should not be included, so "Foo City" or "Foo Peak"
> would both be eligible as "Foo".
> 
> Names which do not meet these criteria but otherwise sound really cool
> should be added to a separate section of the wiki page and the TC may make
> an exception for one or more of them to be considered in the Condorcet poll.
> The naming official is responsible for presenting the list of exceptional
> names for consideration to the TC before the poll opens.
> 
> Exact Geographic Region
> 
> The Geographic Region from where names for the S release will come is Berlin
> 
> Proposed Names
> 
> Spree (a river that flows through the Saxony, Brandenburg and Berlin states of
>   Germany)
> 
> SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)
> 
> Spandau (One of the twelve boroughs of Berlin)
> 
> Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
>   abbreviated as )
> 
> Steglitz (a locality in the South Western part of the city)
> 
> Springer (Berlin is headquarters of Axel Springer publishing house)
> 
> Staaken (a locality within the Spandau borough)
> 
> Schoenholz (A zone in the Niederschönhausen district of Berlin)
> 
> Shellhaus (A famous office building)
> 
> Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)
> 
> Schiller (A park in the Mitte borough)
> 
> Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
>   (The adjective form, Saatwinkler is also a really cool bridge but
>   that form is too long)
> 
> Sonne (Sonnenallee is the name of a large street in Berlin crossing the former
>   wall, also translates as "sun")
> 
> Savigny (Common place in City-West)
> 
> Soorstreet (Street in Berlin restrict Charlottenburg)
> 
> Solar (Skybar in Berlin)
> 
> See (Seestraße or "See Street" in Berlin)
> 
> Thanks,
> Paul
> 
> __
> OpenStack Development Mailing 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