Re: [openstack-dev] [all][sdk] Integrating OpenStack and k8s with a service broker

[Zane Bitter]

Now that the project is set up, let's tag future messages on this topic 
with [service-broker]. Here's one to start with that will help you find 
everything:


http://lists.openstack.org/pipermail/openstack-dev/2018-June/131923.html

cheers,
Zane.

On 05/06/18 12:19, Zane Bitter wrote:
I've been doing some investigation into the Service Catalog in 
Kubernetes and how we can get OpenStack resources to show up in the 
catalog for use by applications running in Kubernetes. (The Big 3 public 
clouds already support this.) The short answer is via an implementation 
of something called the Open Service Broker API, but there are shortcuts 
available to make it easier to do.


I'm convinced that this is readily achievable and something we ought to 
do as a community.


I've put together a (long-winded) FAQ below to answer all of your 
questions about it.


Would you be interested in working on a new project to implement this 
integration? Reply to this thread and let's collect a list of volunteers 
to form the initial core review team.


cheers,
Zane.


What is the Open Service Broker API?


The Open Service Broker API[1] is a standard way to expose external 
resources to applications running in a PaaS. It was originally developed 
in the context of CloudFoundry, but the same standard was adopted by 
Kubernetes (and hence OpenShift) in the form of the Service Catalog 
extension[2]. (The Service Catalog in Kubernetes is the component that 
calls out to a service broker.) So a single implementation can cover the 
most popular open-source PaaS offerings.


In many cases, the services take the form of simply a pre-packaged 
application that also runs inside the PaaS. But they don't have to be - 
services can be anything. Provisioning via the service broker ensures 
that the services requested are tied in to the PaaS's orchestration of 
the application's lifecycle.


(This is certainly not the be-all and end-all of integration between 
OpenStack and containers - we also need ways to tie PaaS-based 
applications into the OpenStack's orchestration of a larger group of 
resources. Some applications may even use both. But it's an important 
part of the story.)


What sorts of services would OpenStack expose?
--

Some example use cases might be:

* The application needs a reliable message queue. Rather than spinning 
up multiple storage-backed containers with anti-affinity policies and 
dealing with the overhead of managing e.g. RabbitMQ, the application 
requests a Zaqar queue from an OpenStack cloud. The overhead of running 
the queueing service is amortised across all of the applications in the 
cloud. The queue gets cleaned up correctly when the application is 
removed, since it is tied into the application definition.


* The application needs a database. Rather than spinning one up in a 
storage-backed container and dealing with the overhead of managing it, 
the application requests a Trove DB from an OpenStack cloud.


* The application includes a service that needs to run on bare metal for 
performance reasons (e.g. could also be a database). The application 
requests a bare-metal server from Nova w/ Ironic for the purpose. (The 
same applies to requesting a VM, but there are alternatives like 
KubeVirt - which also operates through the Service Catalog - available 
for getting a VM in Kubernetes. There are no non-proprietary 
alternatives for getting a bare-metal server.)


AWS[3], Azure[4], and GCP[5] all have service brokers available that 
support these and many more services that they provide. I don't know of 
any reason in principle not to expose every type of resource that 
OpenStack provides via a service broker.


How is this different from cloud-provider-openstack?


The Cloud Controller[6] interface in Kubernetes allows Kubernetes itself 
to access features of the cloud to provide its service. For example, if 
k8s needs persistent storage for a container then it can request that 
from Cinder through cloud-provider-openstack[7]. It can also request a 
load balancer from Octavia instead of having to start a container 
running HAProxy to load balance between multiple instances of an 
application container (thus enabling use of hardware load balancers via 
the cloud's abstraction for them).


In contrast, the Service Catalog interface allows the *application* 
running on Kubernetes to access features of the cloud.


What does a service broker look like?
-

A service broker provides an HTTP API with 5 actions:

* List the services provided by the broker
* Create an instance of a resource
* Bind the resource into an instance of the application
* Unbind the resource from an instance of the application
* Delete the resource

The binding step is used for things like providing a set of DB 
credentials to a container. You can rotate credentials when re

[openstack-dev] [service-broker] openstack-service-broker project update

[Zane Bitter]

(This follows on from 
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131183.html 
in case you are confused)


Hi folks,
Now that the project creation process is largely complete, here are some 
housekeeping updates:


* Let's use the [service-broker] tag in emails to openstack-dev 
(starting with this one!)


* By popular demand, I set up an IRC channel too. It's 
#openstack-service-broker on FreeNode.


* The project repo is available here: 
http://git.openstack.org/cgit/openstack/openstack-service-broker


Since there's no code yet, the only Zuul job is the one to build (but 
not publish) the docs, but it is working and patches are merging.


* As a reminder, this is the current core review team: 
https://review.openstack.org/#/admin/groups/1925,members (and more 
volunteers are welcome)


* The project storyboard is available here: 
https://storyboard.openstack.org/#!/project/1038


* I started adding some stories to the storyboard that should get us to 
an initial prototype, and added them to this worklist: 
https://storyboard.openstack.org/#!/worklist/391


Folks from the Automation Broker team volunteered to help out by writing 
some example playbooks that we can start from. So the most important 
thing I think we can work on to start with is to build the tooling that 
will enable us to test them, both locally for devs and folks checking 
out the project and in the gate.


* It would probably be helpful to set up a meeting time - at least for 
an initial kickoff (thanks Artem for the suggestion), although I see 
we've managed to collect people in just about every time zone so it 
might be challenging. Here is a poll we can use to try to pick a time: 
https://framadate.org/xlKuh4vtozew8gL8 (note: assume all the times are 
in UTC). Everyone who is interested please respond to that in the next 
few days. (I chose the date for July 10th to avoid the days right 
before/after the July 4th holiday in the US, although I personally will 
be around on those days.)


cheers,
Zane.

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

Re: [openstack-dev] [nova] [placement] placement update 18-26

[Chris Dent]

Thanks for the notes Matt, I'll try to incorporate this stuff into
the next one where it makes some. A response within.

On Fri, 29 Jun 2018, Matt Riedemann wrote:

On 6/29/2018 8:03 AM, Chris Dent wrote:

There are a patches left on the consumer generation topic, some tidy
ups, and some stuff related to healing allocations:

* 

Is someone already working on code for making use of this in the
resource tracker?



In what way? The RT, except for I think the Ironic driver, shouldn't be 
dealing with allocations (PUTing them anyway).


I know such things never happen in my writing, but that's basically a
typo. It should say "report client". By which I mean, is anyone
working on handling a generation conflict when PUT /allocations from
nova-scheduler?

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [placement] placement update 18-26

[Matt Riedemann]

On 6/29/2018 8:03 AM, Chris Dent wrote:

# Questions

As far as I can tell there was no discussion on last week's
question, so here it is again:

In [IRC
[last 
week]](http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2018-06-21.log.html#t2018-06-21T13:21:14) 


we had an extensive discussion about being able to set custom
resource classes on the resource provider representing a
compute node, outside the virt driver. At the moment the virt driver
will clobber it. Is this what we always want?



We've always said the virt driver is the "owner" of resource classes for 
the compute node provider right? If something external wants to put 
custom inventory in that tree, they'd do so with a child provider (like 
neutron will do with bandwidth providers).


We have said that we should merge externally-defined traits with 
compute-defined traits, and I think that is OK.




* "How to deploy / model shared disk. Seems fairly straight-forward,
   and we could even maybe create a multi-node ceph job that does
   this - wouldn't that be awesome?!?!", says an enthusiastic Matt
   Riedemann.



Another thing with this is move operations don't really work with shared 
providers yet, there are TODOs in the conductor task code for when we 
move the allocations from the instance on the source host to the 
migration record - those don't deal with shared providers.




## Nested providers in allocation candidates

As far as I can tell the main thing left here is to turn it on in a
microversion. That code is at:

* 


Merged.



## Consumer Generations

There are new patches in progress on this, related to the bugs that
were discovered:

* 
* 

There are a patches left on the consumer generation topic, some tidy
ups, and some stuff related to healing allocations:

* 

Is someone already working on code for making use of this in the
resource tracker?



In what way? The RT, except for I think the Ironic driver, shouldn't be 
dealing with allocations (PUTing them anyway).




* 
   A huge pile of improvements to osc-placement



Several of these are making progress now (getting review I mean), but as 
of <1 hour ago I need to redo something in the bottom change in the series.




* 
   PCPU resource class



I dropped the procedural -2 on this since the spec was never approved in 
time for Rocky.




* 
 


   Blazar's work on using placement


Cool I was just looking at Blazar the other night for interest in the 
dedicated hosts feature request from the public cloud SIG and was 
wondering if they'd started integrating more with placement rather than 
the compute APIs (and notifications). Seems like a good long-term 
strategy on their part.


--

Thanks,

Matt

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

[openstack-dev] [release] [infra] Retiring the release-tools repository

[Jeremy Stanley]

This is just a heads up that the openstack-infra/release-tools Git
repository, previously used by the Release Management team, is
getting retired[*]. Its previous functions have been relocated into
other repositories like openstack-infra/project-config and
openstack/releases. If you have any questions, feel free to follow
up to this notification or pop into the #openstack-release channel
on the Freenode IRC network. Thanks!

[*] https://review.openstack.org/579188
-- 
Jeremy Stanley


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

[openstack-dev] [keystone] Keystone Team Update - Week of 25 June 2018

[Colleen Murphy]

# Keystone Team Update - Week of 25 June 2018

## News

### Policy Auditing

Auditing the keystone APIs and resolving what roles they need under which scope 
types is the next step in implementing basic default roles. This was already 
done for barbican but we still need to go through the exercise for keystone[1]. 
However, the ongoing Flask work[2] will have implications for our policy 
handling and we may want to wait to complete that work before proceeding so 
that we don't end up having to do it twice[3].

[1] 
https://docs.google.com/spreadsheets/d/1kd3OJCLMsIkPgULN31WFw9PA9-3-X99yaDnjWDGOvm0/edit?usp=sharing
[2] https://bugs.launchpad.net/keystone/+bug/1776504
[3] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-26-16.00.log.html#l-56

### Flask Work

The flaskification work has necessitated a new mechanism for policy 
enforcement[4] which will replace @protected. Take a look at the change that 
introduces the RBACEnforcer[5] and try to get familiar with it.

[4] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-26-16.00.log.html#l-229
[5] https://review.openstack.org/576639

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 10 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 57 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 6 new bugs and closed 2.

Bugs opened (6)
Bug #1778603 (keystone:High) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1778603 
Bug #1778945 (keystone:Medium) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1778945 
Bug #1778989 (keystone:Undecided) opened by Lars Kellogg-Stedman 
https://bugs.launchpad.net/keystone/+bug/1778989 
Bug #1779286 (keystone:Undecided) opened by Dmitry 
https://bugs.launchpad.net/keystone/+bug/1779286 
Bug #1778949 (oslo.policy:Undecided) opened by Lance Bragstad 
https://bugs.launchpad.net/oslo.policy/+bug/1778949 
Bug #1779172 (oslo.policy:Undecided) opened by Lance Bragstad 
https://bugs.launchpad.net/oslo.policy/+bug/1779172 

Bugs closed (0) 

Bugs fixed (2) 
Bug #1757022 (keystone:Undecided) fixed by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1757022 
Bug #1778109 (keystone:Undecided) fixed by Jeremy Freudberg 
https://bugs.launchpad.net/keystone/+bug/1778109

This report was generated with http://paste.openstack.org/show/724598/ and 
https://github.com/lbragstad/launchpad-toolkit#building-bug-reports

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Keystone's feature freeze is in just two weeks. Please help out by reviewing 
our major feature work:

https://review.openstack.org/#/q/is:open+topic:bp/mfa-auth-receipt

https://review.openstack.org/#/q/is:open+topic:bp/whitelist-extension-for-app-creds
https://review.openstack.org/#/q/is:open+topic:bp/strict-two-level-model

As well as the flaskification work which will have a major impact on other 
ongoing work:

https://review.openstack.org/#/q/is:open+topic:bug/1776504

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

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

[openstack-dev] [docs][all] Front page template for project team documentation

[Petr Kovar]

Hi all,

Feedback from the Queens PTG included requests for the Documentation
Project to provide guidance and recommendations on how to structure common
content typically found on the front page for project team docs, located at
doc/source/index.rst in the project team repository.

I've created a new docs spec, proposing a template to be used by project
teams, and would like to ask the OpenStack community and, specifically, the
project teams, to take a look, submit feedback on the spec, share
comments, ideas, or concerns:

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

The main goal of providing and using this template is to make it easier for
users to find, navigate, and consume project team documentation, and for
contributors to set up and maintain the project team docs.

The template would also serve as the basis for one of the future governance
docs tags, which is a long-term plan for the docs team.

Thank you,
pk

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

[openstack-dev] [neutron] CI meeting 3.07.2018

[Slawomir Kaplonski]

Hi,

Next week I will not be able to lead CI meeting. As there is also holiday on 
4th July in US, I think that it would be good to cancel this meeting.
Next one will be as usually on 10.07 and Miguel Lavalle will be chair of it.
I’m coming back on 17.07

— 
Slawek Kaplonski
Senior software engineer
Red Hat


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

Re: [openstack-dev] [osc][python-openstackclient] osc-included image signing

[Josephine Seifert]

> On 06/29/2018 05:38 AM, Josephine Seifert wrote:
>> Hello Dean,
>>
>> thanks for your code comments so far.
>>
>>> Looking at the changes you have to cursive, if that is all you need
>>> from it those bits could easily go somewhere in osc or osc-lib if you
>>> don't also need them elsewhere.
>> There lies the problem, because we also want to implement signature
>> generation in nova for the "server image create". Do you have a
>> suggestion, where we could implement this instead of cursive?
>
> I was just chatting with Dean about this in IRC. I'd like to suggest
> putting the image signing code into openstacksdk. Users of
> openstacksdk would almost certainly also want to be able to sign
> images they're going to upload. That would take care of having it in a
> library and also having that library be something OSC depends on.
>
> We aren't using SDK in nova yet - but it shouldn't be hard to get some
> POC patches up to include it ... and to simplify a few other things.
>
> I'd be more than happy to work with you on getting the code in.
>
> Monty

That sounds like a good idea. We will try to integrate the code from
cursive into openstacksdk and update the review, story and etherpad
accordingly.


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

[openstack-dev] [nova] [placement] placement update 18-26

[Chris Dent]

HTML: https://anticdent.org/placement-update-18-26.html

This is placement update 18-26, a weekly update of ongoing
development related to the [OpenStack](https://www.openstack.org/)
[placement
service](https://developer.openstack.org/api-ref/placement/). This
is an expand version.

For the next few weeks the "Specs" section will not be present. When
we start reviewing specs for Stein, I'll add it back in.

# Most Important

Nested allocation candidates are getting very close, but remain a
critical piece of functionality. After that is making sure that we
are progressing on the /reshapher functionality and bringing the
various virt drivers into line with all this nice new functionality
(which mostly means ProviderTrees).

All that nice new functionality means bugs. Experiment. Break stuff.
Find bugs. Fix them.

Speaking of bugs: a collection of problems—not covered by tests—
with consumer generations was discovered this week. Also a problem
with the limit functionality on GET /allocation_candidates and how
that works when force_hosts is being used. Fixes are in progress but
these issues are a strong indicator of our need to make sure that we
are experimenting with things: it's where features integrate with
each other that problems are showing up.

# What's Changed

Quite a lot of bug fixes and bug demonstrations have merged in this
week, but features mostly stable.

# Bugs

* Placement related [bugs not yet in
  progress](https://goo.gl/TgiPXb): 19, two more than last week.
  We've got some work either starting or killing these.
* [In progress placement bugs](https://goo.gl/vzGGDQ) 10, +2 on last
  time.

# Questions

As far as I can tell there was no discussion on last week's
question, so here it is again:

In [IRC
[last 
week]](http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2018-06-21.log.html#t2018-06-21T13:21:14)
we had an extensive discussion about being able to set custom
resource classes on the resource provider representing a
compute node, outside the virt driver. At the moment the virt driver
will clobber it. Is this what we always want?

# Main Themes

## Documentation

This is a section for reminding us to document all the fun stuff we
are enabling. Open areas include:

* Documenting optional placement database. A bug,
  [1778227](https://bugs.launchpad.net/nova/+bug/1778227) has been
  created to track this. This has started, for the install docs, but
  there are more places that need to be touched.

* "How to deploy / model shared disk. Seems fairly straight-forward,
  and we could even maybe create a multi-node ceph job that does
  this - wouldn't that be awesome?!?!", says an enthusiastic Matt
  Riedemann.

* The when's and where's of re-shaping and VGPUs.

## Nested providers in allocation candidates

As far as I can tell the main thing left here is to turn it on in a
microversion. That code is at:

* 

## Consumer Generations

There are new patches in progress on this, related to the bugs that
were discovered:

* 
* 

There are a patches left on the consumer generation topic, some tidy
ups, and some stuff related to healing allocations:

* 

Is someone already working on code for making use of this in the
resource tracker?

## Reshape Provider Trees

This allows moving inventory and allocations that were on resource
provider A to resource provider B in an atomic fashion. The
blueprint topic is:

* 

There are WIPs for the HTTP parts and the resource tracker parts, on
that topic.

## Mirror Host Aggregates

This needs a command line tool:

* 

## Extraction

A while back, Jay made a first pass at an
[os-resource-classes](https://github.com/jaypipes/os-resource-classes/),
which needs some additional eyes on it. I personally thought it
might be heavier than required. If you have ideas please share them.

An area we will need to prepare for is dealing with the various
infra and co-gating issues that will come up once placement is
extracted.

We also need to think about how to manage the fixtures currently
made available by nova that we might need or want to use in
placement. Some of them might be worth sharing. How should we do
that?

# Other

18 entries last week. 24 now.

* 
  Purge comp_node and res_prvdr records during deletion of
  cells/hosts

* 
  A huge pile of improvements to osc-placement

* 
  Get resource provider by uuid or name (osc-placement)

* 
  Tighten up ReportClient use of generation

* 
  Ad

Re: [openstack-dev] [osc][python-openstackclient] osc-included image signing

[Monty Taylor]

On 06/29/2018 05:38 AM, Josephine Seifert wrote:

Hello Dean,

thanks for your code comments so far.


Looking at the changes you have to cursive, if that is all you need
from it those bits could easily go somewhere in osc or osc-lib if you
don't also need them elsewhere.

There lies the problem, because we also want to implement signature
generation in nova for the "server image create". Do you have a
suggestion, where we could implement this instead of cursive?


I was just chatting with Dean about this in IRC. I'd like to suggest 
putting the image signing code into openstacksdk. Users of openstacksdk 
would almost certainly also want to be able to sign images they're going 
to upload. That would take care of having it in a library and also 
having that library be something OSC depends on.


We aren't using SDK in nova yet - but it shouldn't be hard to get some 
POC patches up to include it ... and to simplify a few other things.


I'd be more than happy to work with you on getting the code in.

Monty

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

Re: [openstack-dev] [openstack-ansible] dropping selinux support

[Jean-Philippe Evrard]

This title seems very scary. It was to be read as "... for source installs" : )

To be honest, I feel very sad about the lack of involvement in CentOS
in OSA over the years.
We didn't get many contributors over time for it.
This has always been a labour of love, and the honeymoon seems over for many.

So...
Please help us if you want to keep your sourced based installs +
CentOS + selinux.
Else, you can still use packages! :D

Thanks mnaser for starting this hard topic and community decision process.

JP (evrardjp)

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

Re: [openstack-dev] [tc] [all] TC Report 18-26

[Jean-Philippe Evrard]

My two cents:

> I think if OpenStack wants to gain back some of the steam it had before, it 
> needs to adjust to the new world it is living in. This means:
>  * Consider abolishing the project walls. They are driving bad architecture 
> (not intentionally but as a side affect of structure)

As long as there is no walled garden, everything should be done in a
modular way. I don't think having separated nova from cinder prevented
some contributions, quite the contrary. (Optionally, watch [1]).
I am not familiar with the modularity and ease of contribution in k8s,
so the modularity could be there in a different form.

[1]: https://www.youtube.com/watch?v=xYkh1sAu0UM

>  * focus on the commons first.

Good point.

>  * simplify the architecture for ops:

Good point, but I don't see how code, org structure, or project
classification changes things here.

>  * come up with an architecture team for the whole, not the subsystem. The 
> whole thing needs to work well.

Couldn't that be done with a group TC sponsored?

>  * encourage current OpenStack devs to test/deploy Kubernetes. It has some 
> very good ideas that OpenStack could benefit from. If you don't know what 
> they are, you can't adopt them.

Good idea.

>
> And I know its hard to talk about, but consider just adopting k8s as the 
> commons and build on top of it. OpenStack's api's are good. The 
> implementations right now are very very heavy for ops. You could tie in K8s's 
> pod scheduler with vm stuff running in containers and get a vastly simpler 
> architecture for operators to deal with. Yes, this would be a major 
> disruptive change to OpenStack. But long term, I think it would make for a 
> much healthier OpenStack.

Well, I know operators that wouldn't like k8s and openstack components
on top. If you're talking about just a shim between k8s concepts and
openstack apis, that sounds like a good project : p

>> I've also argued in the past that all distro- or vendor-specific
>> deployment tools (Fuel, Triple-O, etc [3]) should live outside of
>> OpenStack because these projects are more products and the relentless
>> drive of vendor product management (rightfully) pushes the scope of
>> these applications to gobble up more and more feature space that may or
>> may not have anything to do with the core OpenStack mission (and have
>> more to do with those companies' product roadmap).
>
> I'm still sad that we've never managed to come up with a single way to
> install OpenStack. The amount of duplicated effort expended on that
> problem is mind-boggling. At least we tried though. Excluding those
> projects from the community would have just meant giving up from the
> beginning.

Well, I think it's a blessing and a curse.

Sometimes, I'd rather have only one tool, so that we all work on it, and
not dilute the community into small groups.

But when I started deploying OpenStack years ago, I was glad I could
find a community way to deploy it using ,
and not .
So for me, I am glad (what became) OpenStack-Ansible existed and I am
glad it still exists.

The effort your are talking about is not purely duplicated:
- Example: whether openstack-ansible existed or not, people used to
Ansible would still prefer deploying openstack with Ansible
  than with puppet or chef (because of their experience) if not
relying on a vendor. In that case, they would probably create
  their own series of playbooks. (I've seen some). That's the real waste, IMO.
- Deployments projects talk to each other.

Talking about living outside OpenStack, where would, for you,
OpenStack-Ansible, the puppet modules, or OpenStack-Chef be?
For OSA, I consider our community now as NOT vendor specific, as many
actors are now playing with it.
We've spent a considerable effort in outreaching and ensuring everyone
can get involved.
So we should be in openstack/ right? But what about 4 years ago? Every
project starts with a sponsor.

I am not sure a classification (is it outside, is it inside
openstack/?) matters in this case.

>
> I think Thierry's new map, that collects installer services in a
> separate bucket (that may eventually come with a separate git namespace)
> is a helpful way of communicating to users what's happening without
> forcing those projects outside of the community.

Side note: I'd be super happy if OpenStack-Ansible could be on that bucket!

Cheers,
JP (evrardjp)

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

Re: [openstack-dev] [osc][python-openstackclient] osc-included image signing

[Josephine Seifert]

Hello Dean,

thanks for your code comments so far.

> Looking at the changes you have to cursive, if that is all you need
> from it those bits could easily go somewhere in osc or osc-lib if you
> don't also need them elsewhere.
There lies the problem, because we also want to implement signature
generation in nova for the "server image create". Do you have a
suggestion, where we could implement this instead of cursive?

Regards,
Josephine

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

Re: [openstack-dev] [openstack-community] DevStack Installation issue

[Abhijit Dutta]

Hi,


As advised I installed Fedora 27 (Workstation) and tried with the latest 
version of devstack (pulled from git).  However this time I got the following 
error -


./stack.sh:1313:start_placement
/opt/stack/devstack/lib/placement:184:start_placement_api
/opt/stack/devstack/lib/placement:179:die
[ERROR] /opt/stack/devstack/lib/placement:179 placement-api did not start
Error on exit
World dumping... see /opt/stack/logs/worlddump-2018-06-29-071219.txt for details

The local.cnf has been configured as:


[[local|localrc]]
FLOATING_RANGE=192.168.1.224/27
FIXED_RANGE=10.11.12.0/24
FIXED_NETWORK_SIZE=256
FLAT_INTERFACE=eth0
ADMIN_PASSWORD=supersecret
DATABASE_PASSWORD=iheartdatabases
RABBIT_PASSWORD=flopsymopsy
SERVICE_PASSWORD=iheartksl

I have configured a static IP which is 192.168.1.201 in my laptop, which has 
dual core and 3gigs RAM.

Please let me know, what can cause this error.

~Thanx
Abhijit





From: Dr. Jens Harbott (frickler) 
Sent: Wednesday, June 27, 2018 3:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Abhijit Dutta
Subject: Re: [openstack-dev] [openstack-community] DevStack Installation issue

2018-06-27 16:58 GMT+02:00 Amy Marrich :
> Abhijit,
>
> I'm forwarding your issue to the OpenStack-dev list so that the right people
> might see your issue and respond.
>
> Thanks,
>
> Amy (spotz)
>
> -- Forwarded message --
> From: Abhijit Dutta 
> Date: Wed, Jun 27, 2018 at 5:23 AM
> Subject: [openstack-community] DevStack Installation issue
> To: "commun...@lists.openstack.org" 
>
>
> Hi,
>
>
> I am trying to install DevStack for the first time in a baremetal with
> Fedora 28 installed.  While executing the stack.sh I am getting the
> following error:
>
>
> No match for argument: Django
> Error: Unable to find a match
>
> Can anybody in the community help me out with this problem.

We are aware of some issues with deploying devstack on Fedora 28,
these are being worked on, see
https://review.openstack.org/#/q/status:open+project:openstack-dev/devstack+branch:master+topic:uwsgi-f28

If you want a quick solution, you could try deploying on Fedora 27 or
Centos 7 instead.
__
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