Re: [Openstack-operators] Ironic with top-rack switches management

[George Shuklin]

On 01/04/2017 07:31 PM, Clint Byrum wrote:

Excerpts from George Shuklin's message of 2016-12-26 00:22:38 +0200:

Hello everyone.


Did someone actually made Ironic running with ToR (top rack switches)
under neutron in production? Which switch verdor/plugin (and OS version)
do you use? Do you have some switch configuration with parts outside of
Neutron reach? Is it worth spent efforts on integration, etc?


We had an experimental setup with Ironic and the OVN Neutron driver and
VTEP-capable switches (Juniper, I forget the model #, but Arista also has
models that fully support VTEP). It was able to boot baremetal nodes on
isolated L2's (including an isolated provisioning network). In theory this
would also allow VM<->baremetal L2 networking (and with kuryr, you could
get VM<->baremetal<->container working too). But we never proved this
definitively as we got tripped up on scheduling and hostmanager issues
running with ironic in one host agg and libvirt in another. I believe
these are solved, though I've not seen the documentation to prove it.

Few weeks later I can answer may own question.

Most of vendor drivers for Ironic suck. Some of them do not support 
baremetal ports, others have issues with own devices, or have no support 
for newer openstacks.
Nonetheless, there is a great 'networking_generic_switch' ML2 driver 
which can do everything needed to run Ironic with tenant networking. It 
so well-written, that adding new vendor is bearable task for average 
admin. Switch description is just ~15 lines of code with switch-specific 
configuration commands.


Ironic should be at least Newton to support multitenancy.

And it has plenty of bugs, most of which are obvious to fix, but show 
that no one ever done production deployment before (or done, but patched 
it by oneself and kept that patch out of public).

And one more question: Does Ironic support snapshotting of baremetal
servers? With some kind of agent/etc?


I think that's asking too much really. The point of baremetal is that
you _don't_ have any special agents between your workload and hardware.
Consider traditional backup strategies.


But we already have cloud-init in baremetal instances. Why it can't be a 
cloud-backup? Main advantage of openstack-based snapshots for baremetal 
is to have 'golden image' creation. You press button, and your server 
become image. And that image (with proper cloud-init) can boot as VM or 
as baremetal. Convergence at it highest point.


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

Re: [Openstack-operators] [openstack-dev] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC

[joehuang]

Hello,

I read the meeting log and etherpad, and find that you mentioned OPNFV 
Multisite and Kingbird
project. Some comment on these multi-site related projects: OPNFV multisite, 
kingbird, tricircle.

Multisite is a requirement project in OPNFV to identify the gap and requirement 
in OpenStack to make OpenStack work for NFV multi-site cloud.

Kingbird is one sub-project of Multisite, started after gap analysis in OPNFV, 
which is aiming at centralized quota management, centralized view for 
distributed virtual resources, synchronization of ssh keys, images, flavors, 
etc. across regions in OpenStack multi-region deployments. 
Currently the project is working on key-pair sync, and 
centralized quota management feature has been implemented in OPNFV
C release. Kingbird is one major topic in OPNFV Multisite weekly meeting.

While Tricircle is one OpenStack big-tent official project, which was accepted 
in
Nov.2016, and has been narrowed its scope on networking automation across 
Neutron in
OpenStack multi-region deployments during the big-tent application. 
Tricircle has basic features of L2/L3 networking across OpenStack cloud, 
currently local 
network and shared_VLAN based L2/L3 networking are supported, and is working on
VxLAN L2 networking across Neutron, so that L2/L3 networking can also leverage 
the 
VxLAN L2 networking capability. You can refer to (review) the networking guide 
prepared:
https://review.openstack.org/#/c/420316/.

During the discussion happened in 2015 , both kingbird / tricircle are 
candidate 
solutions to address the multisite clouds, Kingbird and Tricircle 
can work together or separately in OpenStack multi-region deployment scenario, 
they are 
complimented each other now. Kingbird has no features about networking 
automation, and Tricircle has no features related to Nova/Cinder...

Tricircle is mostly visible in OpenStack community, while Kingbird is mostly 
visible in OPNFV community.

Welcome to join the meeting:
   Tricircle: IRC meeting: 
https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday 
starting from UTC 13:00
   Multisite & Kingbird: IRC: 
http://webchat.freenode.net/?channels=opnfv-meeting on every Thursday 8:00-9:00 
UTC (During winter time, means CET 9:00 AM).

Best Regards
Chaoyi Huang (joehuang)


From: Anthony SIMONET [anthony.simo...@inria.fr]
Sent: 17 January 2017 22:11
To: openstack-...@lists.openstack.org; OpenStack-operators@lists.openstack.org
Subject: [openstack-dev] [MassivelyDistributed] IRC Meeting tomorrow 15:00  
UTC

Hi all,

The agenda is available at:
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 
82)
Please feel free to add items to the agenda.

The meeting while take place on #openstack-meeting.

Cheers,
Anthony


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

Re: [Openstack-operators] What would you like in Pike?

[Melvin Hillsman]

Well said, as a consequence of this thread being on the mailing list, I
hope that we can get *all* operators, end-users, and app-developers to
respond. If you are aware of folks who do not fall under the "enterprise"
label please encourage them directly to respond; I would encourage everyone
to do the same.

On Tue, Jan 17, 2017 at 11:52 AM, Silence Dogood 
wrote:

> I can see a huge problem with your contributing operators... all of them
> are enterprise.
>
> enterprise needs are radically different from small to medium deployers
> who openstack has traditionally failed to work well for.
>
> On Tue, Jan 17, 2017 at 12:47 PM, Piet Kruithof 
> wrote:
>
>> Sorry for the late reply, but wanted to add a few things.
>>
>> OpenStack UX did suggest to the foundation that the community needs a
>> second survey that focuses exclusively on operators.  The rationale was
>> that the user survey is primarily focused on marketing data and there isn't
>> really a ton of space for additional questions that focuses exclusively on
>> operators. We also recommended a second survey called a MaxDiff study that
>> enabled operators to identify areas of improvement and also rate them in
>> order of importance including distance.
>>
>> There is also an etherpad that asked operators three priorities for
>> OpenStack:
>>
>> https://etherpad.openstack.org/p/mitaka-openstackux-enterprise-goals
>>
>> It was distributed about a year ago, so I'm not sure how much of it was
>> relevant.  The list does include responses from folks at TWC, Walmart,
>> Pacific Northwest Labs, BestBuy, Comcast, NTTi3 and the US government. It
>> might be a good place for the group to add their own improvements as well
>> as "+" other peoples suggestions.
>>
>> There is also a list of studies that have been conducted with operators
>> on behalf of the community. The study included quotas, deployment and
>> information needs. Note that the information needs study extended beyond
>> docs to things like the need to easily google solutions and the need for
>> SMEs.
>>
>> Hope this is helpful.
>>
>> Piet
>>
>> ___
>> OPENSTACK USER EXPERIENCE STATUS
>> The goal of this presentation is to provide an overview of research that
>> was conducted on behalf of the OpenStack community.  All of the studies
>> conducted on behalf of the OpenStack community were included in this
>> presentation.
>>
>> Why this research matters:
>> Consistency across projects has been identified as an issue in the user
>> survey.
>>
>> Study design:
>> This usability study, conducted at the OpenStack Austin Summit, observed
>> 10 operators as they attempted to perform standard tasks in the OpenStack
>> client.
>>
>> https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv
>> 8-tDIQCSingu7zqSMbKFZ_Y/edit#slide=id.p
>>
>>
>>
>> ___
>> USER RESEARCH RESULTS: SEARCHLIGHT/HORIZON INTEGRATION
>> Why this research matters:
>> The Searchlight plug-in for Horizon aims to provide a consistent search
>> API across OpenStack resources. To validate its suitability and ease of
>> use, we evaluated it with cloud operators who use Horizon in their role.
>>
>> Study design:
>> Five operators performed tasks that explored Searchlight’s filters,
>> full-text capability, and multi-term search.
>>
>> https://docs.google.com/presentation/d/1TfF2sm98Iha-bNwBJrCT
>> Cp6k49zde1Z8I9Qthx1moIM/edit?usp=sharing
>>
>>
>>
>> ___
>> CLOUD OPERATOR INTERVIEWS: QUOTA MANAGEMENT AT PRODUCTION SCALE
>> Why this research matters:
>> The study was initiated following operator feedback identifying quotas as
>> a challenge to manage at scale.
>>
>> Study design:
>> One-on-one interviews with cloud operators sought to understand their
>> methods for managing quotas at production scale.
>>
>> https://docs.google.com/presentation/d/1J6-8MwUGGOwy6-A_
>> w1EaQcZQ1Bq2YWeB-kw4vCFxbwM/edit
>>
>>
>>
>> ___
>> CLOUD OPERATOR INTERVIEWS: INFORMATION NEEDS
>> Why this research matters:
>> Documentation has been consistently identified as an issue by operators
>> during the user survey.  However, we wanted to understand the entire
>> workflow associated with identifying and consuming information to resolve
>> issues associated with operating production clouds.
>>
>> Study design:
>> This research consisted of interviews with seven cloud operators from
>> different industries with varying levels of experience to determine how
>> they find solutions to problems that arise.
>>
>> https://docs.google.com/presentation/d/1LKxQx4Or4qOBwPQbt4jA
>> ZncGCLlk_Ez8ZRB_bGp19JU/edit?usp=sharing
>>
>>
>>
>> ___
>> OPERATOR INTERVIEWS: DEPLOYMENT AT PRODUCTION
>> Why this research matters:
>> Deployment has been consistently identified as an issue by operators
>> during the user survey and impacts both adoption and operations of
>> OpenStack.  We wanted to do a deep dive with operators to identify the
>> specific issues impacting deployment.
>>
>> Study design:
>> A series of 1:1 interviews that included 

Re: [Openstack-operators] What would you like in Pike?

[Matt Fischer]

Another +1 for mult-attach please.

On Mon, Jan 16, 2017 at 6:09 AM, Amrith Kumar 
wrote:

> I echo this sentiment; attaching a single Cinder volume or a group of
> volumes in a consistency group to multiple instances would be something I’d
> like to see in Pike.
>
>
>
> -amrith
>
>
>
> *From:* Yaguang Tang [mailto:heut2...@gmail.com]
> *Sent:* Monday, January 16, 2017 7:57 AM
> *To:* Joshua Harlow 
> *Cc:* OpenStack Operators 
> *Subject:* Re: [Openstack-operators] What would you like in Pike?
>
>
>
> I'd like to see this feature  "*Attach a single volume to multiple
> instances*" https://blueprints.launchpad.net/nova/+spec/multi-attach-
> volume to be implmented in Nova side.
>
>
>
> This feature has been working for more than two years, but hasn't been
> accepted by upstream...
>
>
>
> On Sun, Jan 15, 2017 at 2:53 PM, Joshua Harlow 
> wrote:
>
> I'll add a couple:
>
> Cascading deletes,
>
> Ie when a tenant/project/user is removed from keystone there should be
> someway to say deny that request if that tenant/project/user has active
> resources or there should be a away to cascade that delete through the rest
> of those resources (so they are deleted also).
>
> Orphans (not the annie kind),
>
> Pretty sure the osops-tools-generic repo contains a bunch of scripts
> around orphaned items cleanup; this seems *similar* to the above and it
> feels these should be like umm fixed (or those scripts should be deleted if
> its not an issue anymore)?
>
> $ find . | grep -i "orphan"
> ./libvirt/cleanup-orphaned-vms.sh
> ./libvirt/remove-deleted-orphans.sh
> ./neutron/delete_orphan_floatingips.py
> ./neutron/listorphans.py
> ./nova/orphaned_vms.sh
> ./ansible/playbooks/orphaned-vm-clenaup.yaml
> ./ansible/tasks/orphaned-vms.yaml
> ./cinder/orphaned_volumes.sh
>
> Same with https://github.com/openstack/ospurge (which seems like a
> specific project to try to clean this mess up, sorta funny/sad? that it has
> to exist in the first place).
>
> Just search google for 'openstack orphan cleanup' and you'll find more
> scripts and code that people have been writing...
>
> -Josh
>
> Melvin Hillsman wrote:
>
> Hey everyone,
>
> I am hoping to get a dialogue started to gain some insight around things
> Operators, Application Developers, and End Users would like to see
> happen in Pike. If you had a dedicated environment, dedicated team, and
> freedom to choose how you deployed, new features, older features,
> enhancements, etc, and were not required to deal with customer/client
> tickets, calls, and maintenances, could keep a good feedback loop
> between your team and the upstream community of any project, what would
> like to make happen or work on hoping the next release of OpenStack
> had/included/changed/enhanced/removed…?
>
> Kind regards,
>
> --
>
> *Melvin Hillsman*
>
> Ops Technical Lead
>
> OpenStack Innovation Center
>
> _mrhills...@gmail.com _
>
> phone: (210) 312-1267
>
> mobile: (210) 413-1659
>
> Learner | Ideation | Belief | Responsibility | Command
>
> _http://osic.org_
>
> ___
> 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
>
>
>
>
>
> --
>
> Tang Yaguang
>
>
>
>
>
>
>
> ___
> 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] What would you like in Pike?

[Silence Dogood]

I can see a huge problem with your contributing operators... all of them
are enterprise.

enterprise needs are radically different from small to medium deployers who
openstack has traditionally failed to work well for.

On Tue, Jan 17, 2017 at 12:47 PM, Piet Kruithof 
wrote:

> Sorry for the late reply, but wanted to add a few things.
>
> OpenStack UX did suggest to the foundation that the community needs a
> second survey that focuses exclusively on operators.  The rationale was
> that the user survey is primarily focused on marketing data and there isn't
> really a ton of space for additional questions that focuses exclusively on
> operators. We also recommended a second survey called a MaxDiff study that
> enabled operators to identify areas of improvement and also rate them in
> order of importance including distance.
>
> There is also an etherpad that asked operators three priorities for
> OpenStack:
>
> https://etherpad.openstack.org/p/mitaka-openstackux-enterprise-goals
>
> It was distributed about a year ago, so I'm not sure how much of it was
> relevant.  The list does include responses from folks at TWC, Walmart,
> Pacific Northwest Labs, BestBuy, Comcast, NTTi3 and the US government. It
> might be a good place for the group to add their own improvements as well
> as "+" other peoples suggestions.
>
> There is also a list of studies that have been conducted with operators on
> behalf of the community. The study included quotas, deployment and
> information needs. Note that the information needs study extended beyond
> docs to things like the need to easily google solutions and the need for
> SMEs.
>
> Hope this is helpful.
>
> Piet
>
> ___
> OPENSTACK USER EXPERIENCE STATUS
> The goal of this presentation is to provide an overview of research that
> was conducted on behalf of the OpenStack community.  All of the studies
> conducted on behalf of the OpenStack community were included in this
> presentation.
>
> Why this research matters:
> Consistency across projects has been identified as an issue in the user
> survey.
>
> Study design:
> This usability study, conducted at the OpenStack Austin Summit, observed
> 10 operators as they attempted to perform standard tasks in the OpenStack
> client.
>
> https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv8-
> tDIQCSingu7zqSMbKFZ_Y/edit#slide=id.p
>
>
>
> ___
> USER RESEARCH RESULTS: SEARCHLIGHT/HORIZON INTEGRATION
> Why this research matters:
> The Searchlight plug-in for Horizon aims to provide a consistent search
> API across OpenStack resources. To validate its suitability and ease of
> use, we evaluated it with cloud operators who use Horizon in their role.
>
> Study design:
> Five operators performed tasks that explored Searchlight’s filters,
> full-text capability, and multi-term search.
>
> https://docs.google.com/presentation/d/1TfF2sm98Iha-
> bNwBJrCTCp6k49zde1Z8I9Qthx1moIM/edit?usp=sharing
>
>
>
> ___
> CLOUD OPERATOR INTERVIEWS: QUOTA MANAGEMENT AT PRODUCTION SCALE
> Why this research matters:
> The study was initiated following operator feedback identifying quotas as
> a challenge to manage at scale.
>
> Study design:
> One-on-one interviews with cloud operators sought to understand their
> methods for managing quotas at production scale.
>
> https://docs.google.com/presentation/d/1J6-8MwUGGOwy6-
> A_w1EaQcZQ1Bq2YWeB-kw4vCFxbwM/edit
>
>
>
> ___
> CLOUD OPERATOR INTERVIEWS: INFORMATION NEEDS
> Why this research matters:
> Documentation has been consistently identified as an issue by operators
> during the user survey.  However, we wanted to understand the entire
> workflow associated with identifying and consuming information to resolve
> issues associated with operating production clouds.
>
> Study design:
> This research consisted of interviews with seven cloud operators from
> different industries with varying levels of experience to determine how
> they find solutions to problems that arise.
>
> https://docs.google.com/presentation/d/1LKxQx4Or4qOBwPQbt4jAZncGCLlk_
> Ez8ZRB_bGp19JU/edit?usp=sharing
>
>
>
> ___
> OPERATOR INTERVIEWS: DEPLOYMENT AT PRODUCTION
> Why this research matters:
> Deployment has been consistently identified as an issue by operators
> during the user survey and impacts both adoption and operations of
> OpenStack.  We wanted to do a deep dive with operators to identify the
> specific issues impacting deployment.
>
> Study design:
> A series of 1:1 interviews that included included discussions around
> organizations, tools, workflows and pain points associated with deploying
> OpenStack.
>
> https://docs.google.com/presentation/d/14UerMR4HrXKP_0NE_C-
> WJ16YQFzgetL1Tmym9FNFzpY/edit?usp=sharing
>
>
> ___
> OPERATOR USABILITY: OPENSTACKCLIENT
> Why this research matters:
> Consistency across projects has been identified as an issue in the user
> survey.
>
> Study design:
> This usability study, conducted at the OpenStack Austin Summit, observed
> 10 operators as they attempted to perform 

Re: [Openstack-operators] What would you like in Pike?

[Piet Kruithof]

Sorry for the late reply, but wanted to add a few things.

OpenStack UX did suggest to the foundation that the community needs a
second survey that focuses exclusively on operators.  The rationale was
that the user survey is primarily focused on marketing data and there isn't
really a ton of space for additional questions that focuses exclusively on
operators. We also recommended a second survey called a MaxDiff study that
enabled operators to identify areas of improvement and also rate them in
order of importance including distance.

There is also an etherpad that asked operators three priorities for
OpenStack:

https://etherpad.openstack.org/p/mitaka-openstackux-enterprise-goals

It was distributed about a year ago, so I'm not sure how much of it was
relevant.  The list does include responses from folks at TWC, Walmart,
Pacific Northwest Labs, BestBuy, Comcast, NTTi3 and the US government. It
might be a good place for the group to add their own improvements as well
as "+" other peoples suggestions.

There is also a list of studies that have been conducted with operators on
behalf of the community. The study included quotas, deployment and
information needs. Note that the information needs study extended beyond
docs to things like the need to easily google solutions and the need for
SMEs.

Hope this is helpful.

Piet

___
OPENSTACK USER EXPERIENCE STATUS
The goal of this presentation is to provide an overview of research that
was conducted on behalf of the OpenStack community.  All of the studies
conducted on behalf of the OpenStack community were included in this
presentation.

Why this research matters:
Consistency across projects has been identified as an issue in the user
survey.

Study design:
This usability study, conducted at the OpenStack Austin Summit, observed 10
operators as they attempted to perform standard tasks in the OpenStack
client.

https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv8-tDIQCSingu7zqSMbKFZ_Y/edit#slide=id.p




___
USER RESEARCH RESULTS: SEARCHLIGHT/HORIZON INTEGRATION
Why this research matters:
The Searchlight plug-in for Horizon aims to provide a consistent search API
across OpenStack resources. To validate its suitability and ease of use, we
evaluated it with cloud operators who use Horizon in their role.

Study design:
Five operators performed tasks that explored Searchlight’s filters,
full-text capability, and multi-term search.

https://docs.google.com/presentation/d/1TfF2sm98Iha-bNwBJrCTCp6k49zde1Z8I9Qthx1moIM/edit?usp=sharing




___
CLOUD OPERATOR INTERVIEWS: QUOTA MANAGEMENT AT PRODUCTION SCALE
Why this research matters:
The study was initiated following operator feedback identifying quotas as a
challenge to manage at scale.

Study design:
One-on-one interviews with cloud operators sought to understand their
methods for managing quotas at production scale.

https://docs.google.com/presentation/d/1J6-8MwUGGOwy6-A_w1EaQcZQ1Bq2YWeB-kw4vCFxbwM/edit



___
CLOUD OPERATOR INTERVIEWS: INFORMATION NEEDS
Why this research matters:
Documentation has been consistently identified as an issue by operators
during the user survey.  However, we wanted to understand the entire
workflow associated with identifying and consuming information to resolve
issues associated with operating production clouds.

Study design:
This research consisted of interviews with seven cloud operators from
different industries with varying levels of experience to determine how
they find solutions to problems that arise.

https://docs.google.com/presentation/d/1LKxQx4Or4qOBwPQbt4jAZncGCLlk_Ez8ZRB_bGp19JU/edit?usp=sharing




___
OPERATOR INTERVIEWS: DEPLOYMENT AT PRODUCTION
Why this research matters:
Deployment has been consistently identified as an issue by operators during
the user survey and impacts both adoption and operations of OpenStack.  We
wanted to do a deep dive with operators to identify the specific issues
impacting deployment.

Study design:
A series of 1:1 interviews that included included discussions around
organizations, tools, workflows and pain points associated with deploying
OpenStack.

https://docs.google.com/presentation/d/14UerMR4HrXKP_0NE_C-WJ16YQFzgetL1Tmym9FNFzpY/edit?usp=sharing



___
OPERATOR USABILITY: OPENSTACKCLIENT
Why this research matters:
Consistency across projects has been identified as an issue in the user
survey.

Study design:
This usability study, conducted at the OpenStack Austin Summit, observed 10
operators as they attempted to perform standard tasks in the OpenStack
client.

https://docs.google.com/presentation/d/1cBUJuLL9s7JQppVlDBBJMrNNpfqwdkHyfZFuwY6lNgM/edit#slide=id.g1a8df2eaf2_1_0











On Tue, Jan 17, 2017 at 10:07 AM, Jonathan Proulx  wrote:

>
> What Tim said :)
>
> my ordering:
>
> 1) Preemptable Instances -- this would be huge and life changing I'd
>give up any other improvements to get this.
>
> 2) Deeper utilization of nested projects -- mostly we find ways to
>mange with out this but it would be 

Re: [Openstack-operators] What would you like in Pike?

[Jonathan Proulx]

What Tim said :)

my ordering:

1) Preemptable Instances -- this would be huge and life changing I'd
   give up any other improvements to get this.

2) Deeper utilization of nested projects -- mostly we find ways to
   mange with out this but it would be great to have.

   A) to allow research groups (our internal fiscal/administrative
   divisions) to sub divide quota allocations accordinf to their own
   priorities on a self serve basis (provided proper RBAC configs)
   B) to answer show back questions more easily.  Currently with flat
   projects individual research groups have multiple openstack
   projects, by convention we mange to usually be able to aggregaet
   them in reporting, but deing able to show susage by a parent and
   all it 's childeren woudl be very useful

3) Quota improvements -- this is important but we've learned to deal
   with it 

-Jon

On Sat, Jan 14, 2017 at 10:10:40AM +, Tim Bell wrote:
:There are a couple of items which have not been able to make it to the top 
priority for recent releases which would greatly simplify our day to day work 
with the users and make the cloud more flexible. The background use cases are 
described in 
https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html
:
:
:-  Quota management improvements
:
:oManual interventions are often required to sync the current usage with 
the OpenStack view
:
:oNested projects are now in Keystone but is limited support in other 
projects for the end user benefit, such as delegation of quota for sub-projects
:
:-  Nova pre-emptible instances  
(https://review.openstack.org/#/c/104883/) to give spot market functionality
:
:oWe want to run our cloud at near 100% utilisation but this requires rapid 
ejection of lower priority VMs
:
:That having been said, I also fully support key priorities currently being 
worked on such as cells v2 and placement.
:
:Tim
:
:From: Melvin Hillsman 
:Date: Friday, 13 January 2017 at 02:30
:To: openstack-operators 
:Subject: [Openstack-operators] What would you like in Pike?
:
:Hey everyone,
:
:I am hoping to get a dialogue started to gain some insight around things 
Operators, Application Developers, and End Users would like to see happen in 
Pike. If you had a dedicated environment, dedicated team, and freedom to choose 
how you deployed, new features, older features, enhancements, etc, and were not 
required to deal with customer/client tickets, calls, and maintenances, could 
keep a good feedback loop between your team and the upstream community of any 
project, what would like to make happen or work on hoping the next release of 
OpenStack had/included/changed/enhanced/removed…?
:
:Kind regards,
:--
:Melvin Hillsman
:
:Ops Technical Lead
:OpenStack Innovation Center
:
:
:
:mrhills...@gmail.com
:phone: (210) 312-1267
:mobile: (210) 413-1659
:Learner | Ideation | Belief | Responsibility | Command
:
:http://osic.org
:
:

:___
: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

[Openstack-operators] [scientific-wg][scientific] Reminder: IRC Meeting Wednesday 18th 0900 UTC

[Stig Telfer]

Hello all - 

We have a Scientific WG IRC meeting on Wednesday at 0900 UTC on channel 
#openstack-meeting.

The agenda is available here[1] and full IRC meeting details are here[2].

This week we are looking at some upcoming events in the calendar, and then 
talking about federation (in its various forms) and how the WG can contribute 
in this area.

Best wishes,
Stig

[1] 
https://wiki.openstack.org/wiki/Scientific_working_group#IRC_Meeting_January_18th_2016
 

[2] http://eavesdrop.openstack.org/#Scientific_Working_Group 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] What would you like in Pike?

[Edgar Magana]

+1 Sean

The new format will help a lot the communication between people developing 
OpenStack code and people putting in production that code  ;-)

Thanks Melvin!

Edgar

On 1/17/17, 6:51 AM, "Sean Dague"  wrote:

On 01/16/2017 04:02 PM, Jonathan Bryce wrote:
> 
>> On Jan 16, 2017, at 11:03 AM, Matt Riedemann
>> > wrote:
>>
>> On 1/12/2017 7:30 PM, Melvin Hillsman wrote:
>>> Hey everyone,
>>>
>>> I am hoping to get a dialogue started to gain some insight around things
>>> Operators, Application Developers, and End Users would like to see
>>> happen in Pike. If you had a dedicated environment, dedicated team, and
>>> freedom to choose how you deployed, new features, older features,
>>> enhancements, etc, and were not required to deal with customer/client
>>> tickets, calls, and maintenances, could keep a good feedback loop
>>> between your team and the upstream community of any project, what would
>>> like to make happen or work on hoping the next release of OpenStack
>>> had/included/changed/enhanced/removed…?
>>>
>>
>> I just wanted to say thanks for starting this thread. I often wonder
>> what people would like to see the Nova team prioritize because we
>> don't get input from the product work group or Foundation really on
>> big ticket items so we're generally left to prioritizing work on our
>> own each release.
> 
> I agree; thanks Melvin! Great input so far.
> 
> Matt, on the input on big ticket items, I’d love to get your feedback on
> what is missing or you’d like to see more of in the Foundation reports
> or Product Working Group roadmaps to make them more useful for these
> kinds of items. Is this thread more consumable because specific
> functionality is identified over themes? Is it the way it’s scoped to a
> release? We could possibly even add in a similar question (“What would
> you like to see in the next release?”) to the user survey if this is
> info you’ve been looking for.

One of the challenges thus far on PWG input is it has often not been
very grounded in reality. It often misses key details about what's hard,
possible, or easy when it comes to the code and communities in question.
The operator list feedback is typically by teams that are much more
steeped in the day to days of running OpenStack, have sifted through
chunks of the code, chatted more with community members. It very often
starts from a place of much more common ground and understanding.

-Sean

-- 
Sean Dague

https://urldefense.proofpoint.com/v2/url?u=http-3A__dague.net=DwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=OmbLc3AiifQ0yIl6Gecd617rwrT5bR-jZCDZxWAX7Sk=CgcFBkgC4hTz-js-rR0u7U3ENhmBddh9Lzb6suSR8Nk=
 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=OmbLc3AiifQ0yIl6Gecd617rwrT5bR-jZCDZxWAX7Sk=5XnAPd5M5N2o6Y4jOvPm9iNf96_vZMm_-YmASPg_dVA=
 


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

Re: [Openstack-operators] What would you like in Pike?

[Sean Dague]

On 01/16/2017 04:02 PM, Jonathan Bryce wrote:
> 
>> On Jan 16, 2017, at 11:03 AM, Matt Riedemann
>> > wrote:
>>
>> On 1/12/2017 7:30 PM, Melvin Hillsman wrote:
>>> Hey everyone,
>>>
>>> I am hoping to get a dialogue started to gain some insight around things
>>> Operators, Application Developers, and End Users would like to see
>>> happen in Pike. If you had a dedicated environment, dedicated team, and
>>> freedom to choose how you deployed, new features, older features,
>>> enhancements, etc, and were not required to deal with customer/client
>>> tickets, calls, and maintenances, could keep a good feedback loop
>>> between your team and the upstream community of any project, what would
>>> like to make happen or work on hoping the next release of OpenStack
>>> had/included/changed/enhanced/removed…?
>>>
>>
>> I just wanted to say thanks for starting this thread. I often wonder
>> what people would like to see the Nova team prioritize because we
>> don't get input from the product work group or Foundation really on
>> big ticket items so we're generally left to prioritizing work on our
>> own each release.
> 
> I agree; thanks Melvin! Great input so far.
> 
> Matt, on the input on big ticket items, I’d love to get your feedback on
> what is missing or you’d like to see more of in the Foundation reports
> or Product Working Group roadmaps to make them more useful for these
> kinds of items. Is this thread more consumable because specific
> functionality is identified over themes? Is it the way it’s scoped to a
> release? We could possibly even add in a similar question (“What would
> you like to see in the next release?”) to the user survey if this is
> info you’ve been looking for.

One of the challenges thus far on PWG input is it has often not been
very grounded in reality. It often misses key details about what's hard,
possible, or easy when it comes to the code and communities in question.
The operator list feedback is typically by teams that are much more
steeped in the day to days of running OpenStack, have sifted through
chunks of the code, chatted more with community members. It very often
starts from a place of much more common ground and understanding.

-Sean

-- 
Sean Dague
http://dague.net

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

[Openstack-operators] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC

[Anthony SIMONET]

Hi all,

The agenda is available at:
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 
82)
Please feel free to add items to the agenda.

The meeting while take place on #openstack-meeting.

Cheers,
Anthony



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

Re: [Openstack-operators] What would you like in Pike?

[Thierry Carrez]

Matt Riedemann wrote:
> I just read through the blog post [1] about the upcoming Forum at the
> summit. That might help things, at least that's the intent so I'd hope
> it helps. We have had design summit sessions in the past where the nova
> team asks for feedback from operators/users but those were generally not
> well attended (we might get a handful of people). I had assumed the low
> attendance was mostly due to scheduling conflicts and people just had
> other places to be or more important sessions to attend, which is
> understandable when you're trying to pack it all in at the summit.
> 
> [1] http://superuser.openstack.org/articles/openstack-forum/

Yes, that is precisely the intent.

Pike is arguably a bit transitional, since we won't have a "Forum"
happening before the PTG, but that should be the last such cycle. In
future cycles we'll be able to have those "what would you like to see in
the next release" discussions at the Forum, in time for us to discuss
them, turn them into priority blueprints and community goals, and solve
last questions / start working on them at the PTG.

So I'm very happy that Melvin started this "mini-Forum" thread to
compensate while we transition to the new layout :)

-- 
Thierry Carrez (ttx)

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