[Openstack-operators] Contributor Portal PTG Recap
# Contributor Portal Next Steps
## Landing Page Mock ups
* Current mock up:
https://drive.google.com/file/d/0BxMh9oiou2xMLVRvRWRFVklHa2c/view
* Limited click through mock up:
https://invis.io/CSDEZTBDJ#/252645774_Landing
## Todo
- [ ] thingee: A proposal for the *second level* of what the landing page
shows.
- [ ] thingee: Follow up with the Wes and Jimmy at the OpenStack Foundation
for design assistance.
## Communication To The Community
* [Initial
email](http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html)
* [Initial full
thread](http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#118877)
## Highlights from PTG session
[OpenStack Etherpad](https://etherpad.openstack.org/p/contributor-portal)
### TLDR (big changes from discussion)
* Instead of all team on-boarding documentation living in a central
repository, it will still remain with the individual teams to maintain in
their own repository. General documentation (e.g. git, creating accounts,
gerrit setup, etc) will still live in this central repo. If you choose to
contribute by code for example and you pick a project, it will take you
through our general documentation, then the project’s specific documentation.
* This could lead to inconsistencies in documentation design? Confusion
for the reader being sent to different pages?
### General
* We can’t go based off services. Not everything people are contributing
to is a service, so they won't have anything corresponding in the
[service type authority
repo](http://git.openstack.org/cgit/openstack/service-types-authority/tree/service-types.yaml).
There might be a field in projects.yaml that can help with this.
* Remind Thierry on the service type authority repo for
grouping/mapping project.
* Videos were considered, but they’re hard to keep up-to-date.
Previous Documentation PTL Alexandra Settle expressed that even
screenshots can get out of date real fast.
* Generate some kind of crash-course / cheatsheet content for people
who are used to GitHub but not familiar with Gerrit. Aspiers
volunteered for this and made this first pass [ethercalc
sheet](https://ethercalc.openstack.org/github-gerrit).
* Translation team needs to be included
* Provide documentation with how to edit the landing page, since the
source is being hosted on github (there are transition discussions in
place with the infra team and Jimmy)
* Help projects with creating their own contributor guides if they
need to. Think of something like Cookie cutter for setting up the
scaffolding for a new OpenStack project, but getting projects
contributor guides going.
### Upstream Institute
Attendees of the session we’re more in favor of projects keeping
their specific documentation owned in their repositories. As learned
from the centralize documentation problem
[1](http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html)
[2](https://doughellmann.com/blog/2017/08/24/stop-working-so-hard-scaling-open-source-community-practices/)
[3](https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners),
this is a good move. Upstream institute would then use whatever
general documentation is provided. If people get past that, we could
even suggest on-boarding to one of the [top 5 most wanted
help](https://governance.openstack.org/tc/reference/top-5-help-wanted.html)!
### User Committee
Lauren Sell worked with Melvin and others from the user committee to get their
requirements and perspective on the project. Here's an ether pad:
https://etherpad.openstack.org/p/contributor-portal-user-section
### Mock Up Feedback
* Having the service types is great, but on the next level it would
be good to express the code name with a description of what the
project does.
* Combine in events OpenStack day, meetups, forum, ptg, etc.
(emphasize on in person thing)
### Bikeshed
* A word that combines code and documentation ("team(s)" was already
rejected)
--
Mike Perez
signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?
On 9/22/2017 10:02 AM, Volodymyr Litovka wrote: And another topic, in Neutron, regarding domainname. Any DHCP-server, created by Neutron, will return "domain" derived from system-wide "dns_name" parameter (defined in neutron.conf and explicitly used in argument "--domain" of dnsmasq). There is no way to customize this parameter on a per-network basis (parameter "dns_domain" is in action only with Designate, no other ways to use it). Again, it would be great if it will be possible to set per-network domain name in order to deal with DHCP / DNS queries from connected VMs. Per: https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/internal-dns-resolution.html https://developer.openstack.org/api-ref/network/v2/index.html#dns-integration I thought this was all possible since Mitaka such that you could configure neutron and designate to put a DNS domain on a network. That's what Stephen was talking about in the original email, was should we use that, if available, rather than the dhcp_domain option in nova. I think this came up a bit last week in Denver at the PTG, and there was some consensus around doing something like: 1. For a new instance, if the neutron network has a dns_domain set, use it. I'm not totally sure how we tell from the metadata API if it's a new instance or not, except when we're building the config drive, but that could be sorted out. 2. Otherwise use the dhcp_domain config option in nova. -- Thanks, Matt ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?
Hi Stephen, I think, it's useful to have hostname in Nova's metadata - this provides some initial information for cloud-init to configure newly created VM, so I would not refuse this method. A bit confusing is domain part of the hostname (novalocal), which derived from Openstack-wide deprecated-now parameter "dhcp_domain": $ curl http://169.254.169.254/latest/meta-data/hostname jex-n1.novalocal cloud-init qualify this as FQDN and prepare configuration accordingly. Not too critical, but if there would be any way to use user-defined domain part in metadata, it will not break backward compatibility with cloud-init but reduce bustle upon initial VM configuration :) And another topic, in Neutron, regarding domainname. Any DHCP-server, created by Neutron, will return "domain" derived from system-wide "dns_name" parameter (defined in neutron.conf and explicitly used in argument "--domain" of dnsmasq). There is no way to customize this parameter on a per-network basis (parameter "dns_domain" is in action only with Designate, no other ways to use it). Again, it would be great if it will be possible to set per-network domain name in order to deal with DHCP / DNS queries from connected VMs. Thank you. On 9/8/17 12:12 PM, Stephen Finucane wrote: [Re-posting (in edited from) from openstack-dev] Nova has a feature whereby it will provide instance host names that cloud-init can extract and use inside the guest, i.e. this won't happen without cloud- init. These host names are fully qualified domain names (FQDNs) based upon the instance name and local domain name. However, as noted in bug #1698010 [1], the domain name part of this is based up nova's 'dhcp_domain' option, which is a nova-network option that has been deprecated [2]. My idea to fix this bug was to start consuming this information from neutron instead, via the . However, per the feedback in the (WIP) fix [3], this requires requires that the 'DNS Integration' extension works and will introduce a regression for users currently relying on the 'dhcp_domain' option. This suggests it might not be the best approach to take but, alas, I don't have any cleverer ones yet. My initial question to openstack-dev was "are FQDNs a valid thing to use as a hostname in a guest" and it seems they definitely are, even if they're not consistently used [4][5]. However, based on other comments [6], it seems there are alternative approaches and even openstack-infra don't use this functionality (preferring instead to configure hostnames using their orchestration software, if that's what nodepool could be seen as?). As a result, I have a new question: "should nova be in the business of providing this information (via cloud-init and the metadata service) at all"? I don't actually have any clever ideas regarding how we can solve this. As such, I'm open to any and all input. Cheers, Stephen [1] https://bugs.launchpad.net/nova/+bug/1698010 [2] https://review.openstack.org/#/c/395683/ [3] https://review.openstack.org/#/c/480616/ [4] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121948.ht ml [5] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121794.ht ml [6] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121877.ht ml ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
