Re: [openstack-dev] [mistral] Mistral Custom Actions API Design

[Renat Akhmerov]

> One of the pain points for me as an action developer is the OpenStack 
> actions[1].  Since they all use the same method name to retrieve the 
> underlying client, you cannot simply inherit from more than one so you are 
> forced to rewrite the client access methods.  We saw this in creating actions 
> for TripleO[2].  In the base action in TripleO, we have actions that make 
> calls to more than one OpenStack client and so we end up re-writing and 
> maintaining code.  IMO the idea of using multiple inheritance there would be 
> helpful.  It may not require the mixin approach here, but rather a design 
> change in the generator to ensure the method names don't match.
> 
> [1] 
> https://github.com/openstack/mistral/blob/master/mistral/actions/openstack/actions.py
>  
> 
> [2] 
> https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/base.py#L27
>  
> 

I think I’m ok with multiple inheritance if we have a good reason. The question 
is: do we need to have some multiple inheritance in base classes? What you’re 
saying about OpenStack actions just looks like a slightly different discussion 
because they’ve never meant to be base classes, they were not designed with 
this goal in mind. Now, when we’re refactoring the whole subsystem and also 
OpenStack actions we need to revisit their design and think how to make it more 
flexible.

My suggestion here is to move iteratively. I am personally not going to be too 
opinionated about different ideas you’re suggesting. I’d rather merge the one 
that seems the best then reevaluate, change it etc. While mistral-lib is 
considered experimental we can try different options.

Renat Akhmerov
@Nokia


__
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] [oslo] Oslo weekly meeting

[ChangBo Guo]

Hi,

We have weekly Oslo meeting today,  The meeting would be held on Monday UTC
1400 at irc channel #openstack-meeting-3.

Please feel free to add items to the section [High prioritiy items] on
https://etherpad.openstack.org/p/oslo-pike-tracking If you have anything to
raise.

Thanks


-- 
ChangBo Guo(gcb)
__
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] Fwd: How to fix this bug?

[Sam]

Hi all,

I'm installing openstack ocata version, in this step:
https://docs.openstack.org/ocata/install-guide-ubuntu/keystone-users.html
I got error while run 'openstack' command:
Unauthorized: The request you have made requires authentication. (HTTP 401)
(Request-ID: req-1ee39bdd-03b8-4ea8-9432-d027f91c131a)

My env is:
export OS_USERNAME=gateway
export OS_PASSWORD=gateway
export OS_PROJECT_NAME=gateway
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_AUTH_URL=http://controller:35357/v3
export OS_IDENTITY_API_VERSION=3


detail error is as bellow.

All my passwd is set to 'gateway', and I use 'gateway' username not 'admin'
or 'openstack'.

And in https://docs.openstack.org/ocata/install-guide-ubuntu/key
stone-install.html this step, I set every thing as doc said except env as
bellow, but event I set env as doc said(which set OS_USERNAME=admin), I
also got errors as bellow.

So what's wrong? Thank you!

ERROR LOG:
gateway@gateway-virtual-machine:~$ openstack project create --domain
default   --description "Service Project" service
The request you have made requires authentication. (HTTP 401) (Request-ID:
req-cf395e9a-a69f-4a71-9f08-26cb149cb7bd)
gateway@gateway-virtual-machine:~$ openstack project create --domain
default   --description "Service Project" service --debug
START with options: [u'project', u'create', u'--domain', u'default',
u'--description', u'Service Project', u'service', u'--debug']
options: Namespace(access_key='', access_secret='***', access_token='***',
access_token_endpoint='', access_token_type='', auth_type='', auth_url='
http://controller:35357/v3', cacert=None, cert='', client_id='',
client_secret='***', cloud='', code='', consumer_key='',
consumer_secret='***', debug=True, default_domain='default',
default_domain_id='', default_domain_name='', deferred_help=False,
discovery_endpoint='', domain_id='', domain_name='', endpoint='',
identity_provider='', identity_provider_url='', insecure=None,
interface='', key='', log_file=None, old_profile=None, openid_scope='',
os_beta_command=False, os_compute_api_version='',
os_identity_api_version='3', os_image_api_version='',
os_network_api_version='', os_object_api_version='', os_project_id=None,
os_project_name=None, os_volume_api_version='', passcode='',
password='***', profile=None, project_domain_id='',
project_domain_name='Default', project_id='', project_name='gateway',
protocol='', redirect_uri='', region_name='', timing=False, token='***',
trust_id='', url='', user_domain_id='', user_domain_name='Default',
user_id='', username='gateway', verbose_level=3, verify=None)
Auth plugin password selected
auth_config_hook(): {'auth_type': 'password', 'beta_command': False,
u'compute_api_version': u'2', 'key': None, u'database_api_version': u'1.0',
'cacert': None, 'auth_url': 'http://controller:35357/v3',
u'network_api_version': u'2', u'message': u'', u'image_format': u'qcow2',
'networks': [], u'image_api_version': u'2', 'verify': True,
u'dns_api_version': u'2', u'object_store_api_version': u'1', 'username':
'gateway', u'container_infra_api_version': u'1', 'verbose_level': 3,
'region_name': '', 'api_timeout': None, u'baremetal_api_version': u'1',
'auth': {'user_domain_name': 'Default', 'project_name': 'gateway',
'project_domain_name': 'Default'}, 'default_domain': 'default',
u'container_api_version': u'1', u'image_api_use_tasks': False,
u'floating_ip_source': u'neutron', u'orchestration_api_version': u'1',
'timing': False, 'password': '***', u'application_catalog_api_version':
u'1', u'key_manager_api_version': u'v1', u'metering_api_version': u'2',
'deferred_help': False, u'identity_api_version': '3',
u'volume_api_version': u'2', 'cert': None, u'secgroup_source': u'neutron',
u'status': u'active', 'debug': True, u'interface': None,
u'disable_vendor_agent': {}}
defaults: {u'auth_type': 'password', u'status': u'active',
u'compute_api_version': u'2', 'key': None, u'database_api_version': u'1.0',
'api_timeout': None, u'baremetal_api_version': u'1', u'image_api_version':
u'2', u'container_infra_api_version': u'1', u'metering_api_version': u'2',
u'image_api_use_tasks': False, u'floating_ip_source': u'neutron',
u'orchestration_api_version': u'1', 'cacert': None, u'network_api_version':
u'2', u'message': u'', u'image_format': u'qcow2',
u'application_catalog_api_version':
u'1', u'key_manager_api_version': u'v1', 'verify': True,
u'identity_api_version': u'2.0', u'volume_api_version': u'2', 'cert': None,
u'secgroup_source': u'neutron', u'container_api_version': u'1',
u'dns_api_version': u'2', u'object_store_api_version': u'1', u'interface':
None, u'disable_vendor_agent': {}}
cloud cfg: {'auth_type': 'password', 'beta_command': False,
u'compute_api_version': u'2', 'key': None, u'database_api_version': u'1.0',
'cacert': None, 'auth_url': 'http://controller:35357/v3',
u'network_api_version': u'2', u'message': u'', u'image_format': u'qcow2',
'networks': [], u'image_api_version': u'2', 'verify': True,
u'dns_api_version': u'2', 

[openstack-dev] [Murano] Where to find list of Newton Murano bugs, and post-Newton commits

[Waines, Greg]

We have integrated a NEWTON-version of Murano into our OpenStack product.
And are beginning to do some testing of Murano.

Where can I find a current list of bugs that exist in NEWTON-version of MURANO ?
AND
Where can I find a list of post-NEWTON commits to MURANO ?  (i.e. bug fixes, 
enhancements, … towards ocata or pike)

Greg.
__
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] [storlets] Mascot request

[Eran Rom]

Heidi,
Thanks very much for the draft.
The mascot is awesome. I guess I am struggling with how to distinguish a stork 
from a storklet: The mascot looks more like a stork.
I think that what distinguishes a stork chick from other similar chicks (of 
e.g. herons / gannets / ) is the long and thick beak, and not necessarily the 
legs.

Just playing with an idea: How about adding an egg like in the below picture 
replacing the chick with something that has a long neck and thick long beak as 
in the original mascot? or as in one of the original photos 
(http://www.arkive.org/marabou-stork/leptoptilos-crumeniferus/image-G69355.html 
)

Thoughts?
Thanks very much,
Eran



 


> On Mar 10, 2017, at 6:32 PM, Heidi Joy Tretheway  
> wrote:
> 
> Hi Storlets team, 
> 
> Your team selected a storklet as a project mascot, and our illustrators 
> developed this draft. While you sent us a picture of a nesting storklet 
> (where we couldn’t see the legs), the illustrator thought showing the legs 
> would best help distinguish this as a storklet from other birds. Feel free to 
> send feedback my way!
> 
> 
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Clint Byrum]

Excerpts from Fox, Kevin M's message of 2017-03-12 16:54:20 +:
> I totally agree that policy management is a major problem too. A much bigger 
> one then instance users, and something I was hoping to get to after instance 
> users, but never made it past the easier of the two. :/
> 
> 
> The just inject creds solution keeps getting proposed, but only looks at the 
> surface of the issue so has a lot of issues under the hood. Lets dig in again.
> 
> Lets say I create a heat template and inject creds through Parameters, as 
> that is the natural place for a user to fill out settings and launch their 
> application.
> 
> The cred is loaded unencrypted into the heat database. Then heat-engine 
> pushes it into the nova database where it resides unencrypted, so it can be 
> sent to cloud init, usually also in an unencrypted form.
> 
> You delete the heat stack, and the credential still sticks around in the nova 
> database long after the vm is deleted, as it keeps deleted data.
> 
> The channels for passing stuff to a vm are much better at passing config to 
> the vm, not secrets.
> 
> Its also a one shot way to get an initial cred to a vm, but not a way to 
> update it should the need arise. Also, how is the secret maintained in a way 
> that rebooting the vm works while snapshotting the vm doesn't capture the 
> secret, etc.
> 
> The use case/issues are described exhaustively in the spec and describe why 
> its not something thats something that can easily be tackled by "just do X" 
> solutions. I proposed one implementation I think will work generally and 
> cover all bases. But am open to other implementations that cover all the 
> bases. Many half solutions have been proposed, but the whole point is 
> security, so a half solution that has big security holes in it isn't really a 
> solution.
> 

_OR_, you inject a nonce that is used to authenticate the instance to
config management. If you're ever going to talk to anything outside of
the cloud APIs, you'll need this anyway.

Once you're involved with config management you are already sending
credentials of various types to your instances.

__
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][appcat] The future of the App Catalog

[Fox, Kevin M]

I totally agree that policy management is a major problem too. A much bigger 
one then instance users, and something I was hoping to get to after instance 
users, but never made it past the easier of the two. :/


The just inject creds solution keeps getting proposed, but only looks at the 
surface of the issue so has a lot of issues under the hood. Lets dig in again.

Lets say I create a heat template and inject creds through Parameters, as that 
is the natural place for a user to fill out settings and launch their 
application.

The cred is loaded unencrypted into the heat database. Then heat-engine pushes 
it into the nova database where it resides unencrypted, so it can be sent to 
cloud init, usually also in an unencrypted form.

You delete the heat stack, and the credential still sticks around in the nova 
database long after the vm is deleted, as it keeps deleted data.

The channels for passing stuff to a vm are much better at passing config to the 
vm, not secrets.

Its also a one shot way to get an initial cred to a vm, but not a way to update 
it should the need arise. Also, how is the secret maintained in a way that 
rebooting the vm works while snapshotting the vm doesn't capture the secret, 
etc.

The use case/issues are described exhaustively in the spec and describe why its 
not something thats something that can easily be tackled by "just do X" 
solutions. I proposed one implementation I think will work generally and cover 
all bases. But am open to other implementations that cover all the bases. Many 
half solutions have been proposed, but the whole point is security, so a half 
solution that has big security holes in it isn't really a solution.

Thanks,
Kevin





From: Clint Byrum [cl...@fewbar.com]
Sent: Sunday, March 12, 2017 8:30 AM
To: openstack-dev
Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog

Excerpts from Fox, Kevin M's message of 2017-03-11 21:31:40 +:
> No, they are treated as second class citizens. Take Trova again as an 
> example. The underlying OpenStack infrastructure does not provide a good 
> security solution for Trove's use case. As its more then just IaaS. So they 
> have spent years trying to work around it on one way or another, each with 
> horrible trade offs.
>
> For example they could fix an issue by:
> 1. Run the service vm in the users tenant where it belongs. Though, currently 
> the user has permissions to reboot the vm, login through the console and 
> swipe any secrets that are on the vm and make it much harder for the cloud 
> admin to administer.
> 2. Run the vm in a "trove" tenant. This fixes the security issue but breaks 
> the quota model of OpenStack. Users with special host aggregate 
> access/flavors can't work with this model.
>
> For our site, we can't use Trove at all at the moment, even though we want 
> to. Because option 2 doesn't work for us, and option 1 currently has a 
> glaring security flaw in it.
>
> One of the ways I saw Trove try to fix it was to get a feature into Nova 
> called "Service VM's". VMs owned by the user but not fully controllable by 
> them but from some other OpenStack service on their behalf. This, IMO is the 
> right way to solve it. There are a lot of advanced services that need this 
> functionality. But it seems to have been rejected, as "users don't need 
> that"... Which is true, only if you only consider the IaaS use case.
>

You're right. This type of rejection is not O-K IMO, because this is
consumers of Nova with a real use case, asking for real features that
simply cannot be implemented anywhere except inside Nova. Perhaps the
climate has changed, and this effort can be resurrected.

> The problems of these other OpenStack services are being rejected as second 
> class problems, not primary ones.
>
> I'm sure other sites are avoiding other OpenStack advanced services for 
> similar reasons. its not just that Operators don't want to deploy it, or that 
> Users are not asking for it.
>
> Let me try and explain Zane's post in a sligtly different way... maybe that 
> would help...
>
> So, say you had an operating system. It had the ability to run arbitrary 
> programs if the user started an executable via the keyboard/mouse. But had no 
> ability for an executable to start another executable. How useful would that 
> OS be? There would be no shell scripts. No non monolithic applications. It 
> would be sort of functional, but would be hamstrung.
>
> OpenStack is like that today. Like the DOS operating system. Programs are 
> expected to be pretty self contained and not really talk back to the 
> Operating System its running on, nor a way to discover other programs running 
> on the same system. Nor really for a script running on the Operating System 
> to start other programs, chaining them together in a way thats more useful 
> then the sum of their parts. The current view is fine if you need is just a 
> container to run a traditional OS 

Re: [openstack-dev] [tc][keystone][tacker]

[yanxingan]

Thanks, Shake Chen.
Seems barbican is a better way.

On 2017/3/12 22:59, Shake Chen wrote:

Hi
why not use barbican?

On Sun, Mar 12, 2017 at 10:33 PM, yanxin...@cmss.chinamobile.com
 > wrote:


Hi, folks:


Currently tacker server node stores fernet keys for vim password decryption 
on local root file system.
If Tacker service serves API requests through a load balancer, then the 
operation will fail if the request
is not fulfilled by the server node which created and stored the fernet key.

So we need a possible solution for syncing the keys across multiple server 
nodes. Currently we
are
thinking about storing the fernet keys via ceph or swift.
  Do you have any suggestions
on this approach, or does other project has already
dealt with this problem?

Thanks.


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
Shake Chen



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





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

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Clint Byrum]

Excerpts from Fox, Kevin M's message of 2017-03-11 21:31:40 +:
> No, they are treated as second class citizens. Take Trova again as an 
> example. The underlying OpenStack infrastructure does not provide a good 
> security solution for Trove's use case. As its more then just IaaS. So they 
> have spent years trying to work around it on one way or another, each with 
> horrible trade offs.
> 
> For example they could fix an issue by:
> 1. Run the service vm in the users tenant where it belongs. Though, currently 
> the user has permissions to reboot the vm, login through the console and 
> swipe any secrets that are on the vm and make it much harder for the cloud 
> admin to administer.
> 2. Run the vm in a "trove" tenant. This fixes the security issue but breaks 
> the quota model of OpenStack. Users with special host aggregate 
> access/flavors can't work with this model.
> 
> For our site, we can't use Trove at all at the moment, even though we want 
> to. Because option 2 doesn't work for us, and option 1 currently has a 
> glaring security flaw in it.
> 
> One of the ways I saw Trove try to fix it was to get a feature into Nova 
> called "Service VM's". VMs owned by the user but not fully controllable by 
> them but from some other OpenStack service on their behalf. This, IMO is the 
> right way to solve it. There are a lot of advanced services that need this 
> functionality. But it seems to have been rejected, as "users don't need 
> that"... Which is true, only if you only consider the IaaS use case.
> 

You're right. This type of rejection is not O-K IMO, because this is
consumers of Nova with a real use case, asking for real features that
simply cannot be implemented anywhere except inside Nova. Perhaps the
climate has changed, and this effort can be resurrected.

> The problems of these other OpenStack services are being rejected as second 
> class problems, not primary ones.
> 
> I'm sure other sites are avoiding other OpenStack advanced services for 
> similar reasons. its not just that Operators don't want to deploy it, or that 
> Users are not asking for it.
> 
> Let me try and explain Zane's post in a sligtly different way... maybe that 
> would help...
> 
> So, say you had an operating system. It had the ability to run arbitrary 
> programs if the user started an executable via the keyboard/mouse. But had no 
> ability for an executable to start another executable. How useful would that 
> OS be? There would be no shell scripts. No non monolithic applications. It 
> would be sort of functional, but would be hamstrung.
> 
> OpenStack is like that today. Like the DOS operating system. Programs are 
> expected to be pretty self contained and not really talk back to the 
> Operating System its running on, nor a way to discover other programs running 
> on the same system. Nor really for a script running on the Operating System 
> to start other programs, chaining them together in a way thats more useful 
> then the sum of their parts. The current view is fine if you need is just a 
> container to run a traditional OS in. Its not if you are trying to build an 
> application that spans things.
> 
> There have been several attempts at fixing this, in Heat, in Murano, in the 
> App Catalog, but plumbing they rely on isn't really supportive of it, as they 
> believe the use case really is just launching a VM with an OS in it is really 
> the important thing to do, and the job's done.
> 
> For the Applications Catalog to be successful, it needs the underlying cloud 
> to have enough functionality among a common set of cloud provided services to 
> allow applications developers to write cloud software that is redistributable 
> and consumable by the end user. Its failed because the infrastructure just 
> isn't there. The other advanced services are suffering from it too.
> 

I'm not sure I agree. One can very simply inject needed credentials
into a running VM and have it interact with the cloud APIs. However,
there is a deficiency that affects all VM users that might make this
a more desirable option.

There's a lack of a detailed policy management piece. What I'd really
like to inject is an API key that can only do the 2 things my app needs
(like, scale up load balancer, or allocate and attach a volume to itself).
Roles are just too opaque for that to really work well these days.

__
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][keystone][tacker]

[Shake Chen]

Hi
why not use barbican?

On Sun, Mar 12, 2017 at 10:33 PM, yanxin...@cmss.chinamobile.com <
yanxin...@cmss.chinamobile.com> wrote:

>
> Hi, folks:
>
> Currently tacker server node stores fernet keys for vim
> password decryption on local root file system.
> If Tacker service serves API requests through a load balancer,
> then the operation will fail if the request
> is not fulfilled by the server node which created and
> stored the fernet key.
> So we need a possible solution for syncing the keys
> across multiple server nodes. Currently we are
> thinking about storing the fernet keys via ceph or swift.
>   Do you have any suggestions on this approach, or does other project has
> already dealt with this problem?
>
> Thanks.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Shake Chen
__
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][appcat] The future of the App Catalog

[Tim Bell]

> On 11 Mar 2017, at 08:19, Clint Byrum  wrote:
> 
> Excerpts from Christopher Aedo's message of 2017-03-10 19:30:18 -0800:
>> On Fri, Mar 10, 2017 at 6:20 PM, Clint Byrum  wrote:
>>> Excerpts from Fox, Kevin M's message of 2017-03-10 23:45:06 +:
 So, this is the kind of thinking I'm talking about... OpenStack today is
 more then just IaaS in the tent. Trove (DBaaS), Sahara (Hadoop,Spark,etc
 aaS), Zaqar (Messaging aaS) and many more services. But they seem to be
 treated as second class citizens, as they are not "IaaS".
 
>>> 
>>> It's not that they're second class citizens. It's that their community
>>> is smaller by count of users, operators, and developers. This should not
>>> come as a surprise, because the lowest common denominator in any user
>>> base will always receive more attention.
>>> 
> Why should it strive to be anything except an excellent building block
 for other technologies?
 
 You misinterpret my statement. I'm in full agreement with you. The
 above services should be excellent building blocks too, but are suffering
 from lack of support from the IaaS layer. They deserve the ability to
 be excellent too, but need support/vision from the greater community
 that hasn't been forthcoming.
 
>>> 
>>> You say it like there's some over arching plan to suppress parts of the
>>> community and there's a pack of disgruntled developers who just can't
>>> seem to get OpenStack to work for Trove/Sahara/AppCatalog/etc.
>>> 
>>> We all have different reasons for contributing in the way we do.  Clearly,
>>> not as many people contribute to the Trove story as do the pure VM-on-nova
>>> story.
>>> 
 I agree with you, we should embrace the container folks and not treat
 them as separate. I think thats critical if we want to allow things
 like Sahara or Trove to really fulfil their potential. This is the path
 towards being an OpenSource AWS competitor, not just for being able to
 request vm's in a cloudy way.
 
 I think that looks something like:
 OpenStack Advanced Service (trove, sahara, etc) -> Kubernetes ->
 Nova VM or Ironic Bare Metal.
 
>>> 
>>> That's a great idea. However, AFAICT, Nova is _not_ standing in Trove,
>>> Sahara, or anyone else's way from doing this. Seriously, try it. I'm sure
>>> it will work.  And in so doing, you will undoubtedly run into friction
>>> from the APIs. But unless you can describe that _now_, you have to go try
>>> it and tell us what broke first. And then you can likely submit feature
>>> work to nova/neutron/cinder to make it better. I don't see anything in
>>> the current trajectory of OpenStack that makes this hard. Why not just do
>>> it? The way you ask, it's like you have a team of developers just sitting
>>> around shaving yaks waiting for an important OpenStack development task.
>>> 
>>> The real question is why aren't Murano, Trove and Sahara in most current
>>> deployments? My guess is that it's because most of our current users
>>> don't feel they need it. Until they do, Trove and Sahara will not be
>>> priorities. If you want them to be priorities _pay somebody to make them
>>> a priority_.
>> 
>> This particular point really caught my attention.  You imply that
>> these additional services are not widely deployed because _users_
>> don't want them.  The fact is most users are completely unaware of
>> them because these services require the operator of the cloud to
>> support them.  In fact they often require the operator of the cloud to
>> support them from the initial deployment, as these services (and
>> *most* OpenStack services) are frighteningly difficult to add to an
>> already deployed cloud without downtime and high risk of associated
>> issues.
>> 
>> I think it's unfair to claim these services are unpopular because
>> users aren't asking for them when it's likely users aren't even aware
>> of them (do OVH, Vexxhost, Dreamhost, Raskspace or others provide a
>> user-facing list of potential OpenStack services with a voting option?
>> Not that I've ever seen!)
>> 
>> I bring this up to point out how much more popular ALL of these
>> services would be if the _users_ were able to enable them without
>> requiring operator intervention and support.
>> 
>> Based on our current architecture, it's nearly impossible for a new
>> project to be deployed on a cloud without cloud-level admin
>> privileges.  Additionally almost none of the projects could even work
>> this way (with Rally being a notable exception).  I guess I'm kicking
>> this dead horse because for a long time I've argued we need to back
>> away from the tightly coupled nature of all the projects, but
>> (speaking of horses) it seems that horse is already out of the barn.
>> (I really wish I could work in one more proverb dealing with horses
>> but it's getting late on a Friday so I'll stop now.)
>> 
> 
> I see your point, and believe it is valid.
> 
> 

[openstack-dev] [tc][keystone][tacker]

[yanxin...@cmss.chinamobile.com]

Hi, folks:

Currently tacker server node stores fernet keys for vim password decryption 
on local root file system. 
If Tacker service serves API requests through a load balancer, then the 
operation will fail if the request 
is not fulfilled by the server node which created and stored the fernet key.
So we need a possible solution for syncing the keys across multiple server 
nodes. Currently we are 
thinking about storing the fernet keys via ceph or swift. 
  Do you have any suggestions on this approach, or does other project has 
already dealt with this problem?

Thanks.

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

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

[Jeremy Stanley]

On 2017-03-10 13:37:10 -0500 (-0500), Zane Bitter wrote:
[...]
> *That* discussion (the TC vision one) was scheduled to happen in the
> Stewardship Working Group meeting at the PTG in Atlanta:
> https://etherpad.openstack.org/p/AtlantaPTG-SWG-TCVision
> 
> Then it was cancelled because it became clear that most of the TC members
> didn't plan to show up due to scheduling conflicts.

As one of the TC members regrettably unable to attend (because of
still being a PTL at the moment out of necessity, for a team
scheduled to meet on the same days that week), I'm glad we found
time _soon_ after the PTG to do so instead.

> Looking through the TC mailing list, it appears it was rescheduled to happen
> this week at a joint TC/Board meeting in Boston. This looks to be one of the
> outputs: https://etherpad.openstack.org/p/ocata-12questions-exercise-board
> Hopefully we'll hear more in the next few days, since this _just_ happened.
[...]

I'm intentionally not going into detail since the point of the
exercise is to come up with a consistent and unified voice and we're
not yet to the point where it's in a good state to present for
community feedback, but as I have yet to see anyone else from the TC
speak up I will at least say there is an aggressive timeline to have
something circulated throughout the technical community (at least
here in the -dev ML) prior to the Forum in Boston. There were a
handful of TC members unable to attend in person this week (John G.
included), so we're trying to make sure we provide them ample
opportunity for involvement in the early draft stage we're at now.
-- 
Jeremy Stanley

__
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