[Openstack-operators] [app-catalog] App Catalog IRC meeting minutes - 6/18/2015
Thanks to all who joined the meeting this week. After the announcements we had a really good conversation and touched on a few important topics, and there's a lot more to discuss as we work through putting together our near-term roadmap. In addition to the topics noted in the log, we're already seeing progress on a Horizon panel that Kevin has been working on (nice work!) I'll also get a thread started here regarding using an object store for app catalog binary assets as well as a much broader thread regarding cross-project collaboration. Please join us on #openstack-app-catalog during the week, or next Thursday for our next weekly meeting! = #openstack-meeting-3: app-catalog = Meeting started by docaedo at 17:00:38 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-06-18-17.00.log.html . Meeting summary --- * LINK: https://wiki.openstack.org/wiki/Meetings/app-catalog (docaedo, 17:00:58) * rollcall (docaedo, 17:01:09) * Announcements (docaedo, 17:05:46) * LINK: https://review.openstack.org/187863 (docaedo, 17:05:54) * LINK: https://review.openstack.org/189993 (docaedo, 17:05:54) * LINK: https://review.openstack.org/187018 (docaedo, 17:05:54) * ACTION: docaedo start ML discussion re: object store for app catalog (docaedo, 17:06:37) * LINK: https://review.openstack.org/191990 (add site to cacti) (docaedo, 17:06:56) * LINK: https://review.openstack.org/190343 (enable IRC logging) (docaedo, 17:06:56) * LINK: https://review.openstack.org/191478 (mailing list) (docaedo, 17:06:57) * Proposal: stale entries (kfox) (docaedo, 17:09:24) * Versions for entries (docaedo) (docaedo, 17:29:26) * Discussion: ideas for getting more contributors involved? (docaedo, 17:33:37) * Discussion: other topics to cover, longer-term roadmap ideas (docaedo, 17:38:48) Meeting ended at 18:00:31 UTC. Action items, by person --- * docaedo * docaedo start ML discussion re: object store for app catalog People present (lines said) --- * docaedo (108) * kfox (69) * sgordon (52) * kztsv_mbp (16) * ativelkov (10) * muralia (10) * devkulkarni (9) * kebray (7) * datsun180b (3) * openstack (3) * fifieldt (2) * jlk (2) * arunrajan (1) * james_li (1) * jproulx (1) Generated by `MeetBot`_ 0.1.4 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Large Deployments Team] Updated Agenda for Later Today
Mike added our use case to the etherpad [1] today. I talked it over with Carl Baldwin and he seemed ok with the format. If you guys want to add your uses cases to the etherpad - please do, as now is the time to make your voice heard. Mike and I will be at the Neutron mid-cycle to discuss these use cases as well as the initial Neutron Segmentation ask [2]. I believe we will also be discussing the IP usages spec [3] [1] - https://etherpad.openstack.org/p/Network_Segmentation_Usecases [2] - https://bugs.launchpad.net/neutron/+bug/1458890 [3] - https://review.openstack.org/#/c/180803/ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. From: Sam Morrison sorri...@gmail.commailto:sorri...@gmail.com Date: Thursday, June 18, 2015 at 5:44 PM To: Matt Van Winkle mvanw...@rackspace.commailto:mvanw...@rackspace.com Cc: openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] [Large Deployments Team] Updated Agenda for Later Today The auto generated minutes are much appreciated! In terms of segmentation I think our use-cases are pretty much all the same so we should be able to get consensus on an ether pad. Sam On 18 Jun 2015, at 8:15 pm, Matt Van Winkle mvanw...@rackspace.commailto:mvanw...@rackspace.com wrote: Hey folks, Our monthly meeting for LDT is already upon us. I have updated the agenda - https://wiki.openstack.org/wiki/Meetings/LDT. Today, we'll probably spend most of the time discussing some follow-up from our YVR session related to Neutron and segmentation. Kris has done some great work following up on the matter with the devs and we should keep pushing on this. See you all at 16:00 UTC Thanks! Matt ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.orgmailto: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] Specify a domain in mapping rules
Hi all,
I'm a Python/Django software developer [1]. We have to do an integration
of OpenStack and a Shibboleth IdP in my current project.
This is not a easy feature to configure... but finally we got it :-) Now we
only need specify a domain for the user different to the Federated
default domain. This domain depends on an attribute from the IdP.
Is it possible to get with stable/kilo branch? Is it a feature for the next
release? [2] These are my rules:
[
{
local: [
{
user: {
name: {0},
domain: {
name: {1}
}
}
},
{
group: {
id: 0ff59ec2f97646eb9350fe75478f9600
}
}
],
remote: [
{
type: identity
},
{
type: domain
}
]
}
]
I have tested with a lot of rules with little changes:
domain: {
name: Default
}
or
domain: {
id: default
}
or
domain: {
id: 14321243
}
etc... and this never works :-(
Could you help me?
REF's
1. https://github.com/goinnn
2.
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst
Thanks a lot!!,
--
Pablo Martín
Software engineer
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [tags] Ops-Data vs. Ops-Tags
Hi! As promised in the Tags meeting, I bring the discussion on naming to the list. The OpenStack project structure reform that the Technical Committee drove over the past year introduced two concepts. The first one is the big tent, the idea that we should consider as OpenStack projects all the projects produced by the OpenStack Community in the OpenStack Way and furthering the OpenStack Mission. But as we expand and cover more projects, the picture becomes more confusing to the consumers of this ecosystem. Hence the introduction of a second concept: tags providing clear, actionable information about each project. Tags are a class of metadata[1], a controlled vocabulary of labels. They come with a definition, a set of requirements that a project must fulfill to be granted the label. Ideally the requirements are objective, based on available documentation and metrics. But the tag definition itself remains subjective. [1] https://en.wikipedia.org/wiki/Tag_%28metadata%29 As an example, we wanted to provide actionable information about the long-term survivability of a project to the loss of a given corporate sponsor. We defined a team:diverse-affiliation tag, based on a set of contributor demographics requirements, evaluated using Stackalytics metrics. A project meeting the criteria gets the tag. A project not meeting the criteria doesn't get the tag. A simple, binary label, this is what tags are. At the mid-cycle meetup we engaged with the Ops community to get them involved in the definition of operational tags. But as the workgroup started to work, it focused on defining and providing operational data about each project. The state of docs. The state of packaging. The state of deployment. The concepts being defined, and the nature of the data being built, was quite different from tags. It looked more like structured documentation than like labels. Then yesterday I had a revelation. Tags are a second-order construct. You can't define tags or labels out of the blue. You can only define them using existing metrics or documentation as base data. On the development side, we have plenty of data available, so we jumped directly to defining tags. On the operational side though, the base data still needs to be built. It is extremely valuable data. And it is a prerequisite for any operational label. As an example, take the state of packaging (currently proposed under ops:packaged). Which components are packaged ? What is the quality of that packaging ? There is no clear data on it so far, it needs to be gathered and maintained. If we ever want to define a well-packaged label, we need that information gathered and available. So I would like to take a step back and really consider ops-data and tags as two separate, but complementary concepts. Operational data about projects is a necessary first step if we ever want to define operational tags. You should definitely not limit yourself to the tag framework, and define the best ways to gather and convey that information. As a second step, someone may propose tags based on that operational data (I have a few ideas there already), but that is really a second step. That doesn't mean we can't display operational data on the official website describing projects. If the Foundation staff sees value in displaying that information on www.openstack.org, it can certainly be displayed, in parallel to the labels/tags. In conclusion, I'd like to suggest that you find an better name to describe this operational data about projects, because calling them tags or labels will be confusing in this two-step picture. My personal suggestion would be ops-data, but I don't really care which color you paint that bikeshed (as long as it's not blue!). Thanks for reading so far, hoping we can work within the same framework to communicate the best information to all the consumers of our ecosystem. -- Thierry Carrez (ttx) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [tags] Ops-Data vs. Ops-Tags
On 06/19/2015 05:22 AM, Thierry Carrez wrote: In conclusion, I'd like to suggest that you find an better name to describe this operational data about projects, because calling them tags or labels will be confusing in this two-step picture. My personal suggestion would be ops-data +1 -jay ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Configuring migrations in multinode kilo
Abhishek, These article may be useful . - (http://blog.zhaw.ch/icclab/setting-up-live-migration-in-openstack-icehouse/) - (http://docs.openstack.org/admin-guide-cloud/content/section_configuring-compute-migrations.html) If you want to easily try to live-migration , I recommended you change migration-uri from ssh to tcp. So you may need to change the following configuration. - live_migration_uri ( in nova.conf ) from qemu+ssh://hogehoge@%s/system” to “qemu+tcp://%s/system” - listen_tls (in /etc/libvirt/libvirtd.conf ) from “1” to “0” - listen_tcp ( in /etc/libvirt/libvritd.conf ) from “comment out” to “1” - tcp_port ( in /etc/libvirt/libvritd.conf ) from “comment out” to “16509” - auth_tcp ( in /etc/libvirt/libvritd.conf ) from “sasl” to “none” - libvirtd_opts ( in /etc/default/libvirt-bin ) from “-d” to “-d -l” I hope this information help you. Yuki Nishiwaki 2015/06/15 21:04、Abhishek Talwar abhishek.tal...@tcs.com のメール： Hi, I have done a multinode kilo installation with a controller, a network node and two compute nodes. I am able to boot instances on both the compute nodes and they are going in to ACTIVE state. When I am trying to migrate instance from one compute host to the other I am facing an error : [instance: 6cf0c4e2-fc9d-4db5-aeea-314271ea119f] Setting instance back to ACTIVE after: Instance rollback performed due to: Resize error: not able to execute ssh command: Unexpected error while running command. Command: ssh 10.0.0.32 mkdir -p /var/lib/nova/instances/6cf0c4e2-fc9d-4db5-aeea-314271ea119f Exit code: 255 Stdout: u'' Stderr: u'ssh: connect to host 10.0.0.32 port 22: Connection refused\r\n' So how can we configure migrations in a multinode setup ? Why am I getting an SSH error ? Please provide me some information regarding this. I configured passwordless authentication between the nodes thinking it is an SSH probelm but the error remains. Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ 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
