[openstack-dev] [kolla] Berlin summit resume

[Eduardo Gonzalez]

Hi kollagues,

During the Berlin Summit kolla team had a few talks and forum discussions,
as well as other cross-project related topics [0]

First session was ``Kolla project onboarding``, the room was full of people
interested in contribute to kolla, many of them already using kolla in
production environments whiling to make upstream some work they've done
downstream. I can say this talk was a total success and we hope to see many
new faces during this release putting features and bug fixes into kolla.
Slides of the session at [1]

Second session was ``Kolla project update``, was a brief resume of what
work has been done during rocky release and some items will be implemented
in the future. Number of attendees to this session was massive, no more
people could enter the room. Slides at [2]


Then forum sessions..

First one was ``Kolla user feedback``, many users came over the room. We've
notice a big increase in production deployments and some PoC migrating to
production soon, many of those environments are huge.
Overall the impressions was that kolla is great and don't have any big
issue or requirement, ``it works great`` became a common phrase to listen.
Here's a resume of the user feedback needs [3]

- Improve operational usage for add, remove, change and stop/start nodes
and services.
- Database backup and recovery
- Lack of documentation is the bigger request, users need to read the code
to know how to configure other than core/default services
- Multi cells_v2
- New services request, cyborg, masakari and tricircle were the most
requested
- SElinux enabled
- More SDN services such as Contrail and calico
- Possibility to include user's ansible tasks during deploy as well as
support custom config.json
- HTTPS for internal networks

Second one was about ``kolla for the edge``, we've meet with Edge computing
group and others interested in edge deployments to identify what's missing
in kolla and where we can help.
Things we've identified are:

- Kolla seems good at how the service split can be done, tweaking inventory
file and config values can deploy independent environments easily.
- Missing keystone federation
- Glance cache support is not a hard requirement but improves efficiency
(already merged)
- Multi cells v2
- Multi storage per edge/far-edge
- A documentation or architecture reference would be nice to have.

Last one was ``kolla for NFV``, few people came over to discuss about NUMA,
GPU, SRIOV.
Nothing noticiable from this session, mainly was support DPDK for
CentOS/RHEL,OracleLinux and few service addition covered by previous
discussions.

[0] https://etherpad.openstack.org/p/kolla-stein-summit
[1]
https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018
[2]
https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release
[3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback
[4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge
[5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv
__
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] [kolla] Meeting 14-nov-2018 canceled

[Eduardo Gonzalez]

Dear Kolla Team,

Due to the OpenStack Summit in Berlin, the Kolla weekly meeting on
Wednesday 14th is canceled.

Best regards
__
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] [tripleo][openstack-ansible][nova][placement] Owners needed for placement extraction upgrade deployment tooling

[Eduardo Gonzalez]

Hi, from kolla side I've started the work.

In kolla images [0] for now only placement is separated to an independent
image, only source is code is being installed, binary still uses
nova-placement packages until a binary package exists from the debian and
centos families.

In kolla-ansible [1] placement service has been moved into a separate role
applied just before nova.

Things missing for now:
- Binary packages from distributions
- Run db syncs as there is not command for that yet in the master branch
- Apply upgrade process for db changes


[0] https://review.openstack.org/#/c/613589/
[1] https://review.openstack.org/#/c/613629/

Regards

El mié., 31 oct. 2018 a las 10:19, Lee Yarwood ()
escribió:

> On 30-10-18 14:29:12, Emilien Macchi wrote:
> > On the TripleO side, it sounds like Lee Yarwood is taking the lead with a
> > first commit in puppet-placement:
> > https://review.openstack.org/#/c/604182/
> >
> > Lee, can you confirm that you and your team are working on it for Stein
> > cycle?
>
> ACK, just getting back online after being out for three weeks but still
> planning on getting everything in place by the original M2 goal we
> agreed to at PTG. I'll try to post more details by the end of the week.
>
> Cheers,
>
> Lee
>
> > On Thu, Oct 25, 2018 at 1:34 PM Matt Riedemann 
> wrote:
> >
> > > Hello OSA/TripleO people,
> > >
> > > A plan/checklist was put in place at the Stein PTG for extracting
> > > placement from nova [1]. The first item in that list is done in grenade
> > > [2], which is the devstack-based upgrade project in the integrated
> gate.
> > > That should serve as a template for the necessary upgrade steps in
> > > deployment projects. The related devstack change for extracted
> placement
> > > on the master branch (Stein) is [3]. Note that change has some
> > > dependencies.
> > >
> > > The second point in the plan from the PTG was getting extracted
> > > placement upgrade tooling support in a deployment project, notably
> > > TripleO (and/or OpenStackAnsible).
> > >
> > > Given the grenade change is done and passing tests, TripleO/OSA should
> > > be able to start coding up and testing an upgrade step when going from
> > > Rocky to Stein. My question is who can we name as an owner in either
> > > project to start this work? Because we really need to be starting this
> > > as soon as possible to flush out any issues before they are too late to
> > > correct in Stein.
> > >
> > > So if we have volunteers or better yet potential patches that I'm just
> > > not aware of, please speak up here so we know who to contact about
> > > status updates and if there are any questions with the upgrade.
> > >
> > > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html
> > > [2] https://review.openstack.org/#/c/604454/
> > > [3] https://review.openstack.org/#/c/600162/
>
> --
> Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672
> 2D76
> __
> 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] [kolla] ceph osd deploy fails

[Eduardo Gonzalez]

Hi, what version of rocky are you using. Maybe was in the middle of a
backport which temporally broke ceph.

Could you try latest stable/rocky branch?

It is now working properly.

Regards

On Wed, Sep 26, 2018, 2:32 PM Florian Engelmann <
florian.engelm...@everyware.ch> wrote:

> Hi,
>
> I tried to deploy Rocky in a multinode setup but ceph-osd fails with:
>
>
> failed: [xxx-poc2] (item=[0, {u'fs_uuid': u'', u'bs_wal_label':
> u'', u'external_journal': False, u'bs_blk_label': u'',
> u'bs_db_partition_num': u'', u'journal_device': u'', u'journal': u'',
> u'partition': u'/dev/nvme0n1', u'bs_wal_partition_num': u'',
> u'fs_label': u'', u'journal_num': 0, u'bs_wal_device': u'',
> u'partition_num': u'1', u'bs_db_label': u'', u'bs_blk_partition_num':
> u'', u'device': u'/dev/nvme0n1', u'bs_db_device': u'',
> u'partition_label': u'KOLLA_CEPH_OSD_BOOTSTRAP_BS', u'bs_blk_device':
> u''}]) => {
>  "changed": true,
>  "item": [
>  0,
>  {
>  "bs_blk_device": "",
>  "bs_blk_label": "",
>  "bs_blk_partition_num": "",
>  "bs_db_device": "",
>  "bs_db_label": "",
>  "bs_db_partition_num": "",
>  "bs_wal_device": "",
>  "bs_wal_label": "",
>  "bs_wal_partition_num": "",
>  "device": "/dev/nvme0n1",
>  "external_journal": false,
>  "fs_label": "",
>  "fs_uuid": "",
>  "journal": "",
>  "journal_device": "",
>  "journal_num": 0,
>  "partition": "/dev/nvme0n1",
>  "partition_label": "KOLLA_CEPH_OSD_BOOTSTRAP_BS",
>  "partition_num": "1"
>  }
>  ]
> }
>
> MSG:
>
> Container exited with non-zero return code 2
>
> We tried to debug the error message by starting the container with a
> modified endpoint but we are stuck at the following point right now:
>
>
> docker run  -e "HOSTNAME=10.0.153.11" -e "JOURNAL_DEV=" -e
> "JOURNAL_PARTITION=" -e "JOURNAL_PARTITION_NUM=0" -e
> "KOLLA_BOOTSTRAP=null" -e "KOLLA_CONFIG_STRATEGY=COPY_ALWAYS" -e
> "KOLLA_SERVICE_NAME=bootstrap-osd-0" -e "OSD_BS_BLK_DEV=" -e
> "OSD_BS_BLK_LABEL=" -e "OSD_BS_BLK_PARTNUM=" -e "OSD_BS_DB_DEV=" -e
> "OSD_BS_DB_LABEL=" -e "OSD_BS_DB_PARTNUM=" -e "OSD_BS_DEV=/dev/nvme0n1"
> -e "OSD_BS_LABEL=KOLLA_CEPH_OSD_BOOTSTRAP_BS" -e "OSD_BS_PARTNUM=1" -e
> "OSD_BS_WAL_DEV=" -e "OSD_BS_WAL_LABEL=" -e "OSD_BS_WAL_PARTNUM=" -e
> "OSD_DEV=/dev/nvme0n1" -e "OSD_FILESYSTEM=xfs" -e "OSD_INITIAL_WEIGHT=1"
> -e "OSD_PARTITION=/dev/nvme0n1" -e "OSD_PARTITION_NUM=1" -e
> "OSD_STORETYPE=bluestore" -e "USE_EXTERNAL_JOURNAL=false"   -v
> "/etc/kolla//ceph-osd/:/var/lib/kolla/config_files/:ro" -v
> "/etc/localtime:/etc/localtime:ro" -v "/dev/:/dev/" -v
> "kolla_logs:/var/log/kolla/" -ti --privileged=true --entrypoint
> /bin/bash
>
> 10.0.128.7:5000/openstack/openstack-kolla-cfg/ubuntu-source-ceph-osd:7.0.0.3
>
>
>
> cat /var/lib/kolla/config_files/ceph.client.admin.keyring >
> /etc/ceph/ceph.client.admin.keyring
>
>
> cat /var/lib/kolla/config_files/ceph.conf > /etc/ceph/ceph.conf
>
>
> (bootstrap-osd-0)[root@985e2dee22bc /]# /usr/bin/ceph-osd -d
> --public-addr 10.0.153.11 --cluster-addr 10.0.153.11
> usage: ceph-osd -i  [flags]
>--osd-data PATH data directory
>--osd-journal PATH
>  journal file or block device
>--mkfscreate a [new] data directory
>--mkkey   generate a new secret key. This is normally used in
> combination with --mkfs
>--convert-filestore
>  run any pending upgrade operations
>--flush-journal   flush all data out of journal
>--mkjournal   initialize a new journal
>--check-wants-journal
>  check whether a journal is desired
>--check-allows-journal
>  check whether a journal is allowed
>--check-needs-journal
>  check whether a journal is required
>--debug_osdset debug level (e.g. 10)
>--get-device-fsid PATH
>  get OSD fsid for the given block device
>
>--conf/-c FILEread configuration from the given configuration file
>--id/-i IDset ID portion of my name
>--name/-n TYPE.ID set name
>--cluster NAMEset cluster name (default: ceph)
>--setuser USERset uid to user or uid (and gid to user's gid)
>--setgroup GROUP  set gid to group or gid
>--version show version and quit
>
>-drun in foreground, log to stderr.
>-frun in foreground, log to usual location.
>--debug_ms N  set message debug level (e.g. 1)
> 2018-09-26 12:28:07.801066 7fbda64b4e40  0 ceph version 12.2.4
> (52085d5249a80c5f5121a76d6288429f35e4e77b) luminous (stable), process
> (unknown), pid 46
> 2018-09-26 12:28:07.801078 7fbda64b4e40 -1 must specify '-i #' where #
> is the osd number
>
>
> But it looks like "-i" is not set anywere?
>
> grep command
> 

[openstack-dev] [kolla] Proposing Chason Chan (chason) as kolla-ansible core

[Eduardo Gonzalez]

Hi,

I would like to propose Chason Chan to the kolla-ansible core team.

Chason is been working on addition of Vitrage roles, rework VpnaaS service,
maintaining
documentation as well as fixing many bugs.

Voting will be open for 14 days (until 9th of Oct).

Kolla-ansible cores, please leave a vote.
Consider this mail my +1 vote

Regards,
Eduardo
__
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] [kolla] Stein forum topics proposal

[Eduardo Gonzalez]

Hi, Berlin forum brainstorming has started, please add your proposal topics
before 26th september

https://etherpad.openstack.org/p/kolla-forum-stein

Forum topics are proposed the same method as Summit presentations

https://www.openstack.org/summit/berlin-2018/call-for-presentations

Regards
__
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] [kolla] Committing proprietary plugins to OpenStack

[Eduardo Gonzalez]

Hi Shyam,

We offer methods [0] to allow users add their plugins during build time
through template overrides.
This allows extends dockerfiles with custom content as may be your use case.

Also we offer a method to add an external directory into the buildable list
of Dockerfiles with ``--config-dir /mydockerfiles/``

With this two methods you can provide your users the images or the
mechanism to customize their docker images.

In kolla's repository there is a contrib/ folder [1] for
template-overrides, not tested in CI nor supported by the team. Only
examples of things that may work or not about how to extend dockerfiles for
specific use cases.

As example, a patch under review to add overrides for cisco plugins [2]

Regards

[0]
https://docs.openstack.org/kolla/latest/admin/image-building.html#dockerfile-customisation
[1] https://github.com/openstack/kolla/tree/master/contrib/template-override
[2] https://review.openstack.org/#/c/552119/


El vie., 14 sept. 2018 a las 15:20, Steven Dake (stdake) ()
escribió:

> ​Shyam,
>
>
> Our policy, decided long ago, is that we would work with third party
> components (such as plugins) for nova, cinder, neutron, horizon, etc that
> were proprietary as long as the code that merges into Kolla specifically is
> ASL2.
>
>
> What is your plugin for?  if its for nova, cinder, neutron, horizon, it is
> covered by this policy pretty much wholesale.  If its a different type of
> system, some debate may be warranted by the core team.
>
>
> Cheers
>
> -steve
> --
> *From:* Shyam Biradar 
> *Sent:* Wednesday, September 12, 2018 5:01 AM
> *To:* Andreas Jaeger
> *Cc:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [kolla] Committing proprietary plugins to
> OpenStack
>
> Yes Andreas, whatever deployment scripts we will be pushing it will be
> under apache license.
>
> [image: logo]
> *Shyam Biradar*  * Software Engineer | DevOps*
> M +91 8600266938 | shyam.bira...@trilio.io | trilio.io
>
> On Wed, Sep 12, 2018 at 5:24 PM, Andreas Jaeger  wrote:
>
>> On 2018-09-12 13:21, Shyam Biradar wrote:
>>
>>> Hi,
>>>
>>> We have a proprietary openstack plugin. We want to commit deployment
>>> scripts like containers and heat templates to upstream in tripleo and kolla
>>> project but not actual product code.
>>>
>>> Is it possible? Or How can we handle this case? Any thoughts are welcome.
>>>
>>
>> It's first a legal question - is everything you are pushing under the
>> Apache license as the rest of the project that you push to?
>>
>> And then a policy of kolla project, so let me tag them
>>
>> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nür
>> nberg,
>> Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
> __
> 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

[openstack-dev] [kolla] Meeting cancelled

[Eduardo Gonzalez]

Dear Kolla Team,

Due to the PTG in Denver, the Kolla weekly meeting on Wednesday 12th is
canceled.

Best regards
__
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] [kolla][tripleo][openstack-helm][kayobe] Cross-project discussion

[Eduardo Gonzalez]

Hi,

Kolla team is going to have 2 cross-project sessions on Wednesday.

For Tripleo: Addition of healthchecks into kolla images at 10.40 - 11:15,
this is a work

For any project consuming kolla images, CI jobs into kolla CI at 11:20 -
12:00

Hope someone of your teams can attend the sessions.

Regards
__
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] [Kolla] Denver PTG schedule

[Eduardo Gonzalez]

Hi folks,
This is the schedule for Kolla Denver PTG. If someone have a hard conflict
with any discussion please let me know if we can find a slot which matches
better.

Wednesday
9:00 - 9:45 [kolla] Image optimization
9:50 - 10:35 [kolla] Python3 images
10.40 - 11:15 [kolla] Add health checks to kolla images
11:20 - 12:00 [kolla] CI for projects consuming kolla images
12:00 - 13:30 LUNCH
1:30 - 2:15 [kolla-ansible] Compatible OCI runtime
2:20 - 3:05 [kolla-ansible] Backups
3:10 - 3:55 [kolla-ansible] DRY ansible
4:00 - 4:45 [kolla-ansible] Kayobe

Thursday
9:00 - 9:45 [kolla-ansible] Dev mode optimization
9:50 - 10:35 [kolla-ansible] Firewall configuration
10.40 - 11:15 [kolla-ansible] Fast-forward upgrade
11:20 - 12:00 [kolla-ansible] Multi release support
12:00 - 13:30 LUNCH
1:30 - 2:15 [kolla-ansible] Cells v2
2:20 - 3:05 [kolla-ansible] Running kolla at scale
3:10 - 3:55 Kolla GUI
4:00 - 4:45 PTG recap and Stein priority setting

Friday
9:00 - 9:45 [CI] Service testing and scenarios
9:50 - 10:35 [CI] Upgrade jobs
10.40 - 11:15 [CI] Usage of tempest and rally
11:20 - 12:00 Define PTG TODOs (blueprints, specs, etc)
12:00 - 13:30 LUNCH
1:30 - End of day - Open discussion

Regards
__
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] [kolla][project navigator] kolla missing in project navigator

[Eduardo Gonzalez]

Yes, that was my intention. Didn't meant to say kolla as images, i meant
kolla-ansible.

On Mon, Aug 20, 2018, 4:59 PM Thierry Carrez  wrote:

> Eduardo Gonzalez wrote:
> > Hi, effectively kolla-ansible is the deployment tool for container
> > images, and kolla the image artifact builder used by other deployment
> > projects as consumable.
> >
> > In the project navigator wasn't kolla nor kolla-ansible, my bad for not
> > expecifying kolla-ansible as deployment deliverable.
>
> OK, so how about we make sure *Kolla-Ansible* is present both in the map
> and the components list ?
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [kolla][project navigator] kolla missing in project navigator

[Eduardo Gonzalez]

Hi, effectively kolla-ansible is the deployment tool for container images,
and kolla the image artifact builder used by other deployment projects as
consumable.

In the project navigator wasn't kolla nor kolla-ansible, my bad for not
expecifying kolla-ansible as deployment deliverable.

Regards

On Mon, Aug 20, 2018, 4:31 PM Thierry Carrez  wrote:

> Eduardo,
>
> "Kolla" was originally left out of the map (and therefore the new
> OpenStack components page) because the map only shows deliverables that
> are directly usable by deployers. That is why "Kolla-Ansible" is listed
> there and not "Kolla".
>
> Are you making the case that Kolla should be used directly by deployers
> (rather than run it though Ansible with Kolla-Ansible), and therefore
> should appear as a deployment option on the map as well ?
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [kolla][project navigator] kolla missing in project navigator

[Eduardo Gonzalez]

Hi Jimmy, thanks for the the quick update. I see it in the navigator now.

Thanks

On Mon, Aug 20, 2018, 3:57 PM Jimmy McArthur  wrote:

> Eduardo,
>
> Thanks for the heads up.  We're in the process of updating the Project
> Navigator to match the OpenStack Map [1].  It looks like Kolla got lost
> in the shuffle.  I've added it back to the Project [2Navigator under the
> Deployment Tools section [2].
>
> Please let me know if I can assist further.
>
> Thanks,
> Jimmy
>
>
> [1] https://www.openstack.org/assets/software/projectmap/openstack-map.pdf
> [2] https://www.openstack.org/software/project-navigator/deployment-tools
>
> Eduardo Gonzalez wrote:
> > Hi,
> >
> > while checking around the project navigator, I don't see kolla in the
> > deployment tools section.
> >
> > How could we get kolla appear in the navigator along other deployment
> > tools?
> >
> > Regards
> >
> __
> > 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
>
__
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] [kolla][project navigator] kolla missing in project navigator

[Eduardo Gonzalez]

Hi,

while checking around the project navigator, I don't see kolla in the
deployment tools section.

How could we get kolla appear in the navigator along other deployment tools?

Regards
__
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] [kolla-ansible] unable to install kolla-ansible

[Eduardo Gonzalez]

Hi, the interface name must be the same for all nodes including localhost
(deployment host). If the iface names are not the same along all the hosts
will have to:

- Comment network_interface (or the interface var which name differs)
- Set the variable with an appropriate value at inventory file on each
host. In example:
[compute]
node1 network_interface=eth1
node2 network_interface=eno1

Regards

On Sat, Aug 18, 2018, 12:59 PM Hhhtyh ByNhb  wrote:

> Hi All,
> I tried to install openstack kolla by following kolla documentation:
> https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html
>
> When doing this command: "kolla-ansible -i ./multinode bootstrap-servers",
> I observed following error:
> Error message is "fatal: [control01]: FAILED! => {"msg": "The task
> includes an option with an undefined variable. The error was: 'dict object'
> has no attribute 'ipv4'\n\nThe error appears to have been in
> '/usr/local/share/kolla-ansible/ansible/roles/baremetal/tasks/pre-install.yml':
> line 19, column 3, but may\nbe elsewhere in the file depending on the exact
> syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Generate
> /etc/hosts for all of the nodes\n  ^ here\n"}
> Command failed ansible-playbook -i ./multinode -e @/etc/kolla/globals.yml
> -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla  -e
> action=bootstrap-servers
> /usr/local/share/kolla-ansible/ansible/kolla-host.yml
>
> any suggestion?
>
> BR//jaya
>
>
> __
> 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

[openstack-dev] [kolla][ptg] Denver PTG on-site or virtual

[Eduardo Gonzalez]

Fellow kolleages.

In september is Denver PTG, as per the etherpad [0] only 3 contributors
confirmed their presence in the PTG, we expected more people to be there as
previous PTGs were full of contributors and operators.

In the last kolla meeting [1] with discussed if we should make a virtual
PTG rather than a on-site one as we will probably reach a bigger number of
attendance.

This set us in a bad possition as per:

If we do an on-site PTG

- Small representation for a whole cycle design, being this one larger than
usual.
- Many people whiling to attend is not able to be there.

If we do a virtual PTG

- Some people already spend money to travel for kolla PTG
- PTG rooms are already reserved for kolla session
- No cross project discussion

If there are more people who is going to Denver and haven't signed up at
the etherpad, please confirm your presence as it will probably influence on
this topic.

Here is the though question...

What kind of PTG do you prefer for this one, virtual or on-site in Denver?

CC to Kendall Nelson from the foundation if she could help us on this
though decission, given the small time we have until the PTG both ways have
some kind of bad consecuencies for both the project and the contributors.

[0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning
[1]
http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-08-15-15.00.log.html#l-13

Regards
__
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] [kolla] Dropping core reviewer

[Eduardo Gonzalez]

Steve,

Is sad to see you leaving kolla core team, hope to still see you around IRC
and Summit/PTGs.

I truly appreciate your leadership, guidance and commitment to make kolla
the great project it is now.

Best luck on your new projects and board of directors.

Regards





2018-08-07 16:28 GMT+02:00 Steven Dake (stdake) :

> Kollians,
>
>
> Many of you that know me well know my feelings towards participating as a
> core reviewer in a project.  Folks with the ability to +2/+W gerrit changes
> can sometimes unintentionally harm a codebase if they are not consistently
> reviewing and maintaining codebase context.  I also believe in leading an
> exception-free life, and I'm no exception to my own rules.  As I am not
> reviewing Kolla actively given my OpenStack individually elected board of
> directors service and other responsibilities, I am dropping core reviewer
> ability for the Kolla repositories.
>
>
> I want to take a moment to thank the thousands of people that have
> contributed and shaped Kolla into the modern deployment system for
> OpenStack that it is today.  I personally find Kolla to be my finest body
> of work as a leader.  Kolla would not have been possible without the
> involvement of the OpenStack global community working together to resolve
> the operational pain points of OpenStack.  Thank you for your contributions.
>
>
> Finally, quoting Thierry [1] from our initial application to OpenStack,
> " ... Long live Kolla!"
>
>
> Cheers!
>
> -steve
>
>
> [1] https://review.openstack.org/#/c/206789/
>
>
>
>
>
> __
> 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] [kolla] cinder-api image doesn't run as a cinder user.

[Eduardo Gonzalez]

Hi,

See a global openstack goal to move into wsgi
https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
And spec for cinder

https://review.openstack.org/#/c/192683/6/specs/liberty/non-eventlet-wsgi-app.rst

Regards

2018-06-11 14:36 GMT+02:00 Erlon Cruz :

> Hi Eduardo,
>
> Just for curiosity, do you know the motivation why many OS services were
> moved to run on apache instead of just listen? Any reference about that?
>
> Erlon
>
> Em seg, 11 de jun de 2018 às 06:02, Eduardo Gonzalez 
> escreveu:
>
>> Hi,
>>
>> From Pike cinder-api only runs as a wsgi process and container has been
>> migrated into an apache process, currenty we run apache as root user and
>> not as service's user.
>>
>> Regards
>>
>>
>>
>> 2018-06-11 10:46 GMT+02:00 Jae Sang Lee :
>>
>>> Hi, stackers.
>>>
>>> We are distributing OpenStack to kubernetes using the docker image
>>> generated by kolla. I recently upgraded from ocata to pike and found
>>> that the cinder-api container does not run as a cinder user.
>>> So it does not pass our unit test.
>>>
>>> This seems to have been fixed in the following code,
>>> https://review.openstack.org/#/c/463535/2/docker/cinder/
>>> cinder-api/Dockerfile.j2,unified
>>>
>>> Is there a reason why it should not be run as a cinder user? Other
>>> services except cinder-api (cinder-scheduler, cinder-volume,
>>> cinder-backup) are all running as cinder user. If this is a simple bug, try
>>> to fix it.
>>>
>>> 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
>>
>
> __
> 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] [kolla] cinder-api image doesn't run as a cinder user.

[Eduardo Gonzalez]

Hi,

>From Pike cinder-api only runs as a wsgi process and container has been
migrated into an apache process, currenty we run apache as root user and
not as service's user.

Regards



2018-06-11 10:46 GMT+02:00 Jae Sang Lee :

> Hi, stackers.
>
> We are distributing OpenStack to kubernetes using the docker image
> generated by kolla. I recently upgraded from ocata to pike and found that
> the cinder-api container does not run as a cinder user.
> So it does not pass our unit test.
>
> This seems to have been fixed in the following code,
> https://review.openstack.org/#/c/463535/2/docker/cinder/
> cinder-api/Dockerfile.j2,unified
>
> Is there a reason why it should not be run as a cinder user? Other services
>  except cinder-api (cinder-scheduler, cinder-volume, cinder-backup) are
> all running as cinder user. If this is a simple bug, try to fix it.
>
> 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] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

[Eduardo Gonzalez]

+1

2018-06-01 8:57 GMT+02:00 Michał Jastrzębski :

> +1 from me:)
>
> On Thu, May 31, 2018, 11:40 PM Martin André  wrote:
>
>> If Steve wrote half of kolla-cli then it's a no brainer to me. +1!
>>
>> On Thu, May 31, 2018 at 7:02 PM, Borne Mace 
>> wrote:
>> > Greetings all,
>> >
>> > I would like to propose the addition of Steve Noyes to the kolla-cli
>> core
>> > reviewer team.  Consider this nomination as my personal +1.
>> >
>> > Steve has a long history with the kolla-cli and should be considered its
>> > co-creator as probably half or more of the existing code was due to his
>> > efforts.  He has now been working diligently since it was pushed
>> upstream to
>> > improve the stability and testability of the cli and has the second most
>> > commits on the project.
>> >
>> > The kolla core team consists of 19 people, and the kolla-cli team of 2,
>> for
>> > a total of 21.  Steve therefore requires a minimum of 11 votes (so just
>> 10
>> > more after my +1), with no veto -2 votes within a 7 day voting window
>> to end
>> > on June 6th.  Voting will be closed immediately on a veto or in the
>> case of
>> > a unanimous vote.
>> >
>> > As I'm not sure how active all of the 19 kolla cores are, your
>> attention and
>> > timely vote is much appreciated.
>> >
>> > Thanks!
>> >
>> > -- Borne
>> >
>> >
>> > 
>> __
>> > 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
>>
>
> __
> 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] [kolla][vote]Retire kolla-kubernetes project

[Eduardo Gonzalez]

+1

2018-04-19 8:21 GMT+02:00 Christian Berendt 
:

> +1
>
> > On 18. Apr 2018, at 03:51, Jeffrey Zhang 
> wrote:
> >
> > Since many of the contributors in the kolla-kubernetes project are moved
> to other things. And there is no active contributor for months.  On the
> other hand, there is another comparable project, openstack-helm, in the
> community.  For less confusion and disruptive community resource, I propose
> to retire the kolla-kubernetes project.
> >
> > More discussion about this you can check the mail[0] and patch[1]
> >
> > please vote +1 to retire the repo, or -1 not to retire the repo. The
> vote will be open until everyone has voted, or for 1 week until April 25th,
> 2018.
> >
> > [0] http://lists.openstack.org/pipermail/openstack-dev/2018-
> March/128822.html
> > [1] https://review.openstack.org/552531
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> > 
> __
> > 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
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> __
> 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] [kolla][ptg] Team dinner

[Eduardo Gonzalez]

+1

On Mon, Feb 26, 2018, 7:40 PM Paul Bourke  wrote:

> Hey Kolla,
>
> Hope you're all enjoying Dublin so far :) Some have expressed interest
> in getting together for a team meal, how does Thursday sound? Please
> reply to this with +1/-1 and I can see about booking something.
>
> Cheers,
> -Paul
>
> __
> 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] [kolla] Ubuntu jobs failed on pike branch due to package dependency

[Eduardo Gonzalez]

I prefer option 1, breaking stable policy is not good for users. They will
be forced to upgrade a major ceph version during a minor upgrade, which is
not good and not excepted to be done ever.

Regards


2018-02-26 9:51 GMT+01:00 Shake Chen :

> I prefer to the option 2.
>
> On Mon, Feb 26, 2018 at 4:39 PM, Jeffrey Zhang 
> wrote:
>
>> Recently, the Ubuntu jobs on pike branch are red[0]. With some debugging,
>> i found it is caused by
>> package dependency.
>>
>>
>> *Background*
>>
>> Since we have no time to upgrade ceph from Jewel to Luminous at the end
>> of pike cycle, we pinned
>> Ceph to Jewel on pike branch. This works on CentOS, because ceph jewel
>> and ceph luminous are on
>> the different repos.
>>
>> But in Ubuntu Cloud Archive repo, it bump ceph to Luminous. Even though
>> ceph luminous still exists
>> on UCA. But since qemu 2.10 depends on ceph luminous, we have to ping
>> qemu to 2.5 to use ceph Jewel[1].
>> And this works since then.
>>
>>
>> *Now Issue*
>>
>> But recently, UCA changed the libvirt-daemon package dependency, and
>> added following,
>>
>> Package: libvirt-daemon
>> Version: 3.6.0-1ubuntu6.2~cloud0
>> ...
>> Breaks: qemu (<< 1:2.10+dfsg-0ubuntu3.4~), qemu-kvm (<<
>> 1:2.10+dfsg-0ubuntu3.4~)
>>
>> It requires qemu 2.10 now. So dependency is broken and nova-libvirt
>> container is failed to build.
>>
>>
>> *Possible Solution*
>>
>> I think there two possible ways now, but none of them is good.
>>
>> 1. install ceph Luminuous on nova-libvirt container and ceph Jewel in
>> ceph-* container
>> 2. Bump ceph from jewel to luminous. But this breaks the backport policy,
>> obviously.
>>
>> So any idea on this?
>>
>> [0] https://review.openstack.org/534149
>> [1] https://review.openstack.org/#/c/526931/
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [kolla]Fwd: [Openstack-stable-maint] Stable check of openstack/kolla failed

[Eduardo Gonzalez]

Hi, thanks for the advice. Will take a look.

Regards

On Mon, Feb 19, 2018, 8:28 AM Matthias Runge  wrote:

> On Sun, Feb 18, 2018 at 05:15:18AM -0600, Sean McGinnis wrote:
> > Hello kolla team,
> >
> > It looks like stable builds for kolla have been failing for some time
> now. Just forwarding this on to make sure the team is aware of it before
> the need for a stable release comes up.
> >
> > > Build failed.
> > >
> > > - build-openstack-sphinx-docs
> http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/build-openstack-sphinx-docs/b0f5081/html/
> : SUCCESS in 2m 50s
> > > - openstack-tox-py27
> http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/openstack-tox-py27/b6577a4/
> : SUCCESS in 2m 27s
> > > - kolla-publish-centos-source
> http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-source/29e3a2b/
> : POST_FAILURE in 1h 16m 44s
> > > - kolla-publish-centos-binary
> http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-binary/dc12a93/
> : POST_FAILURE in 1h 08m 48s (non-voting)
> > > - kolla-publish-ubuntu-source
> http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-source/dd419ce/
> : POST_FAILURE in 56m 40s
> > > - kolla-publish-ubuntu-binary
> http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-binary/a7fca30/
> : POST_FAILURE in 52m 05s (non-voting)
> > > - kolla-publish-oraclelinux-source
> http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-source/7e87ef0/
> : POST_FAILURE in 1h 35m 59s
> > > - kolla-publish-oraclelinux-binary
> http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-binary/56eb5bd/
> : POST_FAILURE in 1h 42m 57s (non-voting)
>
> This one is differs significantly from the other build failures.
>
> Previously, only both ubuntu-related builds failed.
>
> Matthias
> --
> Matthias Runge 
>
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham,
> Michael O'Neill, Eric Shander
>
> __
> 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] [kolla] LXD driver in nova

[Eduardo Gonzalez]

Hi João,

It would be possible but there is not any  container image with the
nova-lxc code on it at the moment. (No binary rpm in RDO neither)

Only supported drivers (for now) are: kvm, qemu, vmware and hyperv (xen in
progress).

Feel free to add lxd as driver into the project :)

Regards

2018-01-04 11:42 GMT+01:00 João Paulo Sá da Silva <
joao-sa-si...@alticelabs.com>:

> Hello!
>
>
>
> Is it possible to use the LXD driver for nova compute instead of the KVM?
>
>
>
> Kind regards,
>
> João
>
> __
> 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] [kolla] Vxlan and OVS issues post deployment.

[Eduardo Gonzalez]

Hi Goutham,

VXLAN tunnels are created between network/compute hosts in expected
interface (ens3):

df_default="true", in_key=flow, local_ip="192.168.122.215",
out_key=flow, remote_ip="192.168.122.177"

Where is exactly failing? Instances not get IP, DHCP does not work,
vm-to-vm traffic issues, public traffic issues?

Regards


2017-11-30 11:26 GMT+01:00 Goutham Pratapa <pratapagout...@gmail.com>:

> Hi Eduardo,
>
> I am trying to deploy self-service network topology.
>
> I think then I shouldn't be bothered about the `ens8` because I'm not
> dealing with provider networks
>
> and attached are the outputs requested...
>
> Ps: Controller and the network node are both same in my setup.
>
> Thanks in advance
>
> Goutham
>
> On Thu, Nov 30, 2017 at 3:33 PM, Eduardo Gonzalez <dabar...@gmail.com>
> wrote:
>
>> Hi,
>>
>> In kolla,VXLAN  tunnels are connfigured in ``tunnel_interface`` variable
>> which defaults to ``network_interface``, ``neutron_external_interface`` is
>> used for public floating IPs in neutron.
>>
>> Please share your globals.yml, ``ip a`` output in compute/network hosts
>> and ``ovs-vsctl show`` from openvswitch daemon containers.
>>
>> What network topology are you trying to deploy? Self-service, provider
>> networks, etc?
>>
>> Regards
>>
>>
>> 2017-11-30 10:42 GMT+01:00 Jeffrey Zhang <zhang.lei@gmail.com>:
>>
>>> i guess you didn't enabled one of following[0]
>>>
>>>   enable_neutron_dvr: yes
>>>   enable_neutron_provider_networks: yes
>>>
>>> I hit this recently. i am thinking we should remove this or make
>>> enable_neutron_provider_network=yes in default.
>>>
>>> [0] https://github.com/openstack/kolla-ansible/blob/master/a
>>> nsible/group_vars/all.yml#L607
>>>
>>>
>>> On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa <
>>> pratapagout...@gmail.com> wrote:
>>>
>>>> Hi Kolla Team,
>>>>
>>>> I have tried deploying Kolla OpenStack multinode and I am facing this
>>>> issue vxlan_peers_not_created
>>>> <https://ask.openstack.org/en/question/110570/vxlan-peers-not-being-created-on-compute-node-vm-not-getting-dhcp/>
>>>> in every deployment and I* tried the workaround* i.e restart the
>>>> network  containers to get the vxlan peers
>>>>
>>>> But when I see *ip addr show *in my compute node.
>>>>
>>>> *P.S:* "ens8"  is the interface I specified as
>>>> *neutron_external_interface** in globals.yml*
>>>>
>>>>
>>>> * Globals.yml-*
>>>>
>>>>
>>>>
>>>>
>>>> *# This is the raw interface given to neutron as its external network
>>>> port. Even# though an IP address can exist on this interface, it will be
>>>> unusable in most# configurations. It is recommended this interface not be
>>>> configured with any IP# addresses for that reason.*
>>>>
>>>> *neutron_external_interface: "ens8"*3: ens8:
>>>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
>>>> group default qlen 1000
>>>> link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
>>>> inet 192.168.122.218/24 scope global ens8
>>>>valid_lft forever preferred_lft forever
>>>> inet6 fe80::5054:ff:fe54:b350/64 scope link
>>>>valid_lft forever preferred_lft forever
>>>>
>>>> Which should be something like the below (as per my understanding) for
>>>> the Vms to be up and running.
>>>>
>>>> 3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
>>>> *master
>>>> ovs-system* state UP group default qlen 1000
>>>> link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
>>>> inet 192.168.122.165/32 scope global ens8
>>>>valid_lft forever preferred_lft forever
>>>> inet6 fe80::5054:ff:fe22:4bcf/64 scope link
>>>>valid_lft forever preferred_lft forever
>>>>
>>>> Is this a known issue ??
>>>>
>>>> If yes any workaround to solve??
>>>>
>>>> Thanks in advance.
>>>> --
>>>> Thanks!!!
>>>> Goutham Pratapa
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mail

Re: [openstack-dev] [kolla] Vxlan and OVS issues post deployment.

[Eduardo Gonzalez]

Hi,

In kolla,VXLAN  tunnels are connfigured in ``tunnel_interface`` variable
which defaults to ``network_interface``, ``neutron_external_interface`` is
used for public floating IPs in neutron.

Please share your globals.yml, ``ip a`` output in compute/network hosts and
``ovs-vsctl show`` from openvswitch daemon containers.

What network topology are you trying to deploy? Self-service, provider
networks, etc?

Regards


2017-11-30 10:42 GMT+01:00 Jeffrey Zhang :

> i guess you didn't enabled one of following[0]
>
>   enable_neutron_dvr: yes
>   enable_neutron_provider_networks: yes
>
> I hit this recently. i am thinking we should remove this or make
> enable_neutron_provider_network=yes in default.
>
> [0] https://github.com/openstack/kolla-ansible/blob/
> master/ansible/group_vars/all.yml#L607
>
>
> On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa  > wrote:
>
>> Hi Kolla Team,
>>
>> I have tried deploying Kolla OpenStack multinode and I am facing this
>> issue vxlan_peers_not_created
>> 
>> in every deployment and I* tried the workaround* i.e restart the
>> network  containers to get the vxlan peers
>>
>> But when I see *ip addr show *in my compute node.
>>
>> *P.S:* "ens8"  is the interface I specified as
>> *neutron_external_interface** in globals.yml*
>>
>>
>> * Globals.yml-*
>>
>>
>>
>>
>> *# This is the raw interface given to neutron as its external network
>> port. Even# though an IP address can exist on this interface, it will be
>> unusable in most# configurations. It is recommended this interface not be
>> configured with any IP# addresses for that reason.*
>>
>> *neutron_external_interface: "ens8"*3: ens8:
>>  mtu 1500 qdisc pfifo_fast state UP
>> group default qlen 1000
>> link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.122.218/24 scope global ens8
>>valid_lft forever preferred_lft forever
>> inet6 fe80::5054:ff:fe54:b350/64 scope link
>>valid_lft forever preferred_lft forever
>>
>> Which should be something like the below (as per my understanding) for
>> the Vms to be up and running.
>>
>> 3: ens8:  mtu 1500 qdisc pfifo_fast *master
>> ovs-system* state UP group default qlen 1000
>> link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
>> inet 192.168.122.165/32 scope global ens8
>>valid_lft forever preferred_lft forever
>> inet6 fe80::5054:ff:fe22:4bcf/64 scope link
>>valid_lft forever preferred_lft forever
>>
>> Is this a known issue ??
>>
>> If yes any workaround to solve??
>>
>> Thanks in advance.
>> --
>> Thanks!!!
>> Goutham Pratapa
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [kolla] Compute fails to startup

[Eduardo Gonzalez]

Hi Goutham,

Please share your nova-compute and libvirt logs from
/var/lib/docker/volumes/kolla_logs/_data/nova.

What kolla release is deployed?
If using nested virtualization, is correctly configured to use qemu instead
of kvm?

Regards

2017-11-21 15:37 GMT+01:00 Goutham Pratapa :

> Hi all,
>
> I have been trying to deploy Kolla on a virtualized environment with
> Centos Docker images using the
>
> stable/pike branch
>
> Deployment fails with -- https://hastebin.com/gubilijecu.vbs
> Inventory fail -- https://hastebin.com/etosipegez.pl
> extra log -- https://hastebin.com/yudafudegu.go
> Docker logs https://hastebin.com/imotenanob.cs
> Gloabls.yml https://hastebin.com/ihamepanim.coffeescript
>
> Any help would be of great use ???
>
> Thanks in advance...
>
> Thank you !!!
> Goutham Pratapa
>
> __
> 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] [kolla] Host networking in Kolla

[Eduardo Gonzalez]

Hi Akshay.

Yes, kolla support segregate almost all traffic in different interfaces. By
default all traffic uses network_interface, but you can specify any of the
following variables under Network configuration section.
https://docs.openstack.org/kolla-ansible/latest/admin/production-architecture-guide.html

Regards

On Mon, Nov 13, 2017, 1:30 PM Goutham Pratapa 
wrote:

> Hi all,
>
> Does OpenStack-Kolla support Host-networking (separate network for
> management, traffic, and storage)
> ( 
> https://docs.openstack.org/newton/install-guide-rdo/environment-networking.html
> )
>
> Any ideas ??
>
>
> Thanks in advance
>
> --
> Thanks !!!
> Goutham Pratapa
> __
> 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] [kolla] Proposal to add Marcin (hrw) to kolla images core team

[Eduardo Gonzalez]

+1 good contributions

2017-11-02 16:58 GMT+01:00 Michał Jastrzębski :

> It's my great pleasure to start another voting for core team addition!
>
> Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
> Voting will be open for 14 days (until 16th of Nov).
>
> Consider this mail my +1 vote
>
> Regards,
> Michal
>
> __
> 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

[openstack-dev] [tacker] vim fernet keys HA deployment

[Eduardo Gonzalez]

Hi,

While deploying master multinode realized vim fernet keys are created
locally only in one node unless barbican is used. This causes only be able
to run one tacker-server service simultaneously.

Question: Is there a method in tacker to make HA multinode without barbican
and without shared storage for vim fernet directory.

This is similar to a glance deployment with file based backend.

Regards
__
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] [tacker] Self-nomination for PTL in Queens

[Eduardo Gonzalez]

Hi Yong,

Kolla already deploy tacker since ocata :)

Regards

On Wed, Aug 9, 2017, 7:30 AM gongys2017  wrote:

> Hi everyone,
>
> This is my self-nomination to continue running as Takcer PTL for the
> Queens cycle.
>
> In Pike cycle, tacker team is focusing on stablebility and scaling. We have
> introtroduced Barbican to keep VIM credentials and Mistral to do VIM
> monitoring and policies. These are great steps to let Tacker to be stable
> and scalable. In addition, the team has been active in promoting tacker.
> We have joined OPNFV meeting, OpenStack days China and OpenStack
> design summit in Boston.  There are some topic sessions which are
> proposed to Syndey Summit by team.
>
> In Queen cycle, I plan to
>
> - Continue to stablize tacker and make it of production quality.
> - Complete tacker document.
> - Provide kolla way to install tacker. I think tacker will be installed in
> kolla which put
>   tacker in containers. The container way will make tacker easier to use,
>   help many guys to use tacker in short way, compared to devstack
> installation.
> - introduce more kinds of VIMs
> - Promote tacker into other community.
>
> Lets make tacker roll together.
>
> Thanks for your consideration.
>
> --
>
> Thanks,
>
> yong sheng gong
> __
> 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] [kolla][kolla-ansible] Proposing Surya (spsurya) for core

[Eduardo Gonzalez]

+1

2017-06-22 11:12 GMT+01:00 Christian Berendt :

> +1
>
> > On 14. Jun 2017, at 17:46, Michał Jastrzębski  wrote:
> >
> > Hello,
> >
> > With great pleasure I'm kicking off another core voting to
> > kolla-ansible and kolla teams:) this one is about spsurya. Voting will
> > be open for 2 weeks (till 28th Jun).
> >
> > Consider this mail my +1 vote, you know the drill:)
> >
> > Regards,
> > Michal
> >
> > 
> __
> > 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
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> __
> 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] [kolla][osprofiler][keystone][neutron][nova] osprofiler in paste deploy files

[Eduardo Gonzalez]

Hi Matt,

A), As far I can see most services with Osprofile implemented have it
enabled by default at paste-ini files except Neutron and maybe a couple
more.

B), kolla's custom keystone-paste-ini file will probably be "removed" for
Pike release, using keystone defaults with osprofile enabled. We will add
other method to customize paste-ini, ofc.

C), For now in kolla, neutron paste-ini cannot be customized by regular
methods, a quick but no good solution would be exec into container, modify
the file and restart container, or modify kolla-ansible playbooks to allow
copying your custom api-paste.ini.

Agree that option A is the best method.

FYI, at this moment there is a change under review to implement osprofile
in kolla-ansible. [0]

[0] https://review.openstack.org/#/c/455628/

Regards, Eduardo
__
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] [kolla][kolla-ansible] Proposing Bertrand Lallau for kolla and kolla-ansible core

[Eduardo Gonzalez]

Count with my +1

2017-05-02 16:30 GMT+01:00 Michał Jastrzębski :

> Hello,
>
> It's my pleasure to start another core reviewer vote. Today it's
> Bertrand (blallau). Consider this mail my +1 vote. Members of
> kolla-ansible and kolla core team, please cast your votes:) Voting
> will be open for 2 weeks (until 16th of May).
>
> I also wanted to say that Bertrand went through our core mentorship
> program (if only for few weeks because he did awesome job before too)
> :)
>
> Thank you,
> Michal
>
> __
> 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] Emails for OpenStack R Release Name voting going out - please be patient

[Eduardo Gonzalez]

Hi all,
is there any new about the mailing issue? Still not received mine.

Regards

On Thu, Apr 13, 2017, 1:51 AM Sean McGinnis  wrote:

> On Wed, Apr 12, 2017 at 05:27:13PM -0500, Jay S Bryant wrote:
> > I also didn't receive an e-mail.  :-(
> >
> I don't think we need to perpetuate this thread for everybody
> that didn't get it. I think it's safe to see that a large number
> of folks have not recieved the email. (Me included) :)
>
>
> __
> 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

[openstack-dev] [keystone] Field 'domain_id' doesn't have a default value

[Eduardo Gonzalez]

Hi.
I’m testing upgrades from Newton to master branch using keystone’s
zero-downtime upgrade method:

keystone-manage db_sync --expand
keystone-manage db_sync --migrate
keystone-manage db_sync --contract

After upgrade is made with no errors in logs, I cannot create users. Other
keystone commands works fine.

Error message: “Field ‘domain_id’ doesn’t have a default value”

Full trace:

2017-01-26 15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters
[req-576e5683-6631-49b9-b532-65f06a23bbeb
4b3ff53812734e72b5aea42103349571 04fe68cf58724855a2ee67781a14b446 -
default default] DBAPIError exception wrapped from
(pymysql.err.InternalError) (1364, u"Field 'domain_id' doesn't have a
default value") [SQL: u'INSERT INTO user (id, enabled, extra,
default_project_id, created_at, last_active_at) VALUES (%(id)s,
%(enabled)s, %(extra)s, %(default_project_id)s, %(created_at)s,
%(last_active_at)s)'] [parameters: {'last_active_at': None, 'extra':
'{}', 'created_at': datetime.datetime(2017, 1, 26, 15, 32, 10,
974903), 'enabled': 1, 'default_project_id': None, 'id':
'8989be945c954f14a1c9ebaf45988fad'}]2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters Traceback (most recent call
last):2017-01-26 15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters
 File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 1139, in _execute_context2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters context)2017-01-26 15:32:10.978 17
ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/sqlalchemy/engine/default.py",
line 450, in do_execute2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters cursor.execute(statement,
parameters)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/cursors.py",
line 167, in execute2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters result =
self._query(query)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/cursors.py",
line 323, in _query2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters conn.query(q)2017-01-26
15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 836, in query2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters self._affected_rows =
self._read_query_result(unbuffered=unbuffered)2017-01-26 15:32:10.978
17 ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 1020, in _read_query_result2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters result.read()2017-01-26
15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 1303, in read2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters first_packet =
self.connection._read_packet()2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 982, in _read_packet2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters packet.check_error()2017-01-26
15:32:10.978 17 ERROR oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/connections.py",
line 394, in check_error2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters
err.raise_mysql_exception(self._data)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/err.py", line
120, in raise_mysql_exception2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters
_check_mysql_exception(errinfo)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters   File
"/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/err.py", line
115, in _check_mysql_exception2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters raise InternalError(errno,
errorvalue)2017-01-26 15:32:10.978 17 ERROR
oslo_db.sqlalchemy.exc_filters InternalError: (1364, u"Field
'domain_id' doesn't have a default value")2017-01-26 15:32:10.978 17
ERROR oslo_db.sqlalchemy.exc_filters

Database migration logs:

2017-01-26 15:27:11.425 18 INFO migrate.versioning.api [-] 4 -> 5...
2017-01-26 15:27:11.540 18 INFO migrate.versioning.api [-]
done2017-01-26 15:27:11.540 18 INFO migrate.versioning.api [-] 5 ->
6... 2017-01-26 15:27:11.643 18 INFO migrate.versioning.api [-]
done2017-01-26 15:27:11.645 18 INFO migrate.versioning.api [-] 6 ->
7... 2017-01-26 15:27:11.758 18 INFO migrate.versioning.api [-]
done2017-01-26 15:27:11.759 18 INFO migrate.versioning.api [-] 7 ->
8... 2017-01-26 15:27:11.872 18 INFO migrate.versioning.api [-]
done2017-01-26 15:27:11.879 18 INFO migrate.versioning.api [-] 8 ->
9... 2017-01-26 15:27:12.082 18 INFO 

Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

[Eduardo Gonzalez]

My vote for option 2 to deprecate Debian images.
Since the last deprecation vote nobody tried to maintain Debian images.
No gates, not tested and not maintained sound like good reasons to
deprecate Debian.

Regards

2017-01-19 10:53 GMT+00:00 Christian Berendt :

> As discussed in one of the last team meetings I want to propose the
> deprecation (this cycle) and removal (next cycle) of the Debian support in
> Kolla.
>
> More than 1 week ago I sent a pre warning mail to the openstack-operators
> mailing list, without any reply [0].
>
> Kolla core reviewers, please vote now. The vote will be open for 7 days
> (26.01.2017).
>
> 1. Kolla needs support for Debian, it should not be deprecated
>
> 2. Kolla should deprecate support for Debian
>
> [0] http://lists.openstack.org/pipermail/openstack-operators/
> 2017-January/012427.html
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> __
> 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

[openstack-dev] [kolla] Services consuming RabbitMQ

[Eduardo Gonzalez]

Hi all,

At this moment we have a couple of services that need to consume
connections from a message queue on the client side.

This raised change requests to fix the issue with different approaches.
Those change requests have several implications on Kolla's overall
architecture and security, being said, will need a discussion for message
queue consumers from client side in order to apply the best solution,
avoiding as far we can all risk in the infrastructure.


As far as I know, murano-agent and trove-agent need to connect to RabbitMQ
in order to consume configurations and status tracking from the deployed
services. The agent is installed in the instances. [0] [1]


Using Murano as example, when a new application is deployed, murano-agent
configuration is injected in the instances through cloud-init with RabbitMQ
connection information (user, URL and password). Once the instance start,
murano-agent communicates with murano-engine through RabbitMQ in order to
get application configurations.


As we have in Kolla at the moment, Murano won't work unless using older
Murano applications on which the application has been previously installed
and configured in the base image.


>From this design I have three different options to fix the issue.



   -

   Allow services to use actual RabbitMQ cluster in a different vhost: [3]
   [4]
   -

  Pros:
  -

 Easy to fix now, there are PS under review at the moment for
 Murano.
 -

 Provides some kind of isolation per service as well as more secure
 with different user/password.
 -

  Cons:
  -

 Expose OpenStack infrastructure RabbitMQ to to end-users.
 -

 Risk of DDoS attacks to the whole OpenStack infrastructure,
 end-user instances will have access to a shared RabbitMQ
between OpenStack
 and them.
 -

   New RabbitMQ instances (per service or shared with other services): [5]
   -

  Pros:
  -

 More secure option, avoid DDoS against the infrastructure and
 network access to OpenStack RabbitMQ.
 -

  Cons:
  -

 Overload underlay infrastructure with more RabbitMQ instances.
 -

 Inability to use standard ports because more than one RabbitMQ can
 share the same node.
 -

 Complex option to deploy, debug and maintain.
 -

   Expose current RabbitMQ to end-user services.
   -

  Pros:
  -

 Simple, easy and less resource consuming.
 -

  Cons:
  -

 Hell no, this is not an option.
 -

 Share OpenStack's RabbitMQ cluster admin password and expose
 network access to end-users.



There is a thread which explains the issue and solutions recommended by
other teams. [6]


Please, share your opinion on this matter.


[0]
https://github.com/openstack/murano/blob/master/doc/source/administrator-guide/murano_agent.rst

[1] https://wiki.openstack.org/wiki/Trove/guest_agent_communication

[3] https://review.openstack.org/#/c/410825/

[4] https://review.openstack.org/#/c/411760/

[5] https://review.openstack.org/#/c/374525/

[6] http://www.gossamer-threads.com/lists/openstack/operators/57816



Regards, Eduardo Gonzalez
__
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] [kolla] Vote to add zhubingbing to core team

[Eduardo Gonzalez]

+1 great job

2016-11-30 2:48 GMT+00:00 Steven Dake (stdake) :

> +1 from me ☺
>
> -Original Message-
> From: Michał Jastrzębski 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, November 29, 2016 at 9:21 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [kolla] Vote to add zhubingbing to core team
>
> Hello team!
>
> I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
> core teams. He did great job reviewing code during last couple of
> months.
>
> Consider this proposal +1 from me, voting will be open for 1 week
> (until Dec 6) or if we get unanimous agreement (or veto) before.
>
> Regards,
> Michal
>
> 
> __
> 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
>
__
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] [kolla] Propose removal of TrivialFix requirement

[Eduardo Gonzalez]

+1


2016-11-04 13:32 GMT+00:00 Jeffrey Zhang :

> +1
>
> On Fri, Nov 4, 2016 at 8:51 PM, Ryan Hallisey  wrote:
>
>> +1
>>
>> -Ryan
>>
>> - Original Message -
>> From: "Swapnil Kulkarni" 
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Sent: Friday, November 4, 2016 8:48:49 AM
>> Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix
>> requirement
>>
>> On Thu, Nov 3, 2016 at 6:51 PM, Paul Bourke 
>> wrote:
>> > Kolleagues,
>> >
>> > How do people feel above removing the requirement of having TrivialFix
>> in
>> > commit messages where a bug/bp is not required?
>> >
>> > I'm seeing a lot of valid and important commits being held up because of
>> > this, in my opinion, unnecessary requirement. It also causes friction
>> for
>> > new contributers to the project.
>> >
>> > Are there any major benefits we're getting from the use of this tag
>> that I'm
>> > missing?
>> >
>> > Cheers,
>> > -Paul
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> I feel TrivialFix is consistently used by people just to avoid going
>> to lanuchpad and filing a bug. It should only be used only if the "Fix
>> is Trivial"
>> This has been well documented in the contributing doc [1] and this
>> should be referred to people when they do not have the bug/bp in the
>> commit message.
>>
>> If the commits are important then there is no harm in creating a
>> tracking bug for it.
>> It would take 1/30(I am just making highest time for a build/deploy
>> gate) amount of time you need to verify the (important)fix on gate.
>>
>> [1] docs.openstack.org/developer/kolla/CONTRIBUTING.html
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [vote][kolla] deprecation for fedora distro support

[Eduardo Gonzalez]

+1 to option 2.

Regards

On Mon, Sep 19, 2016, 10:34 PM Vikram Hosakote (vhosakot) <
vhosa...@cisco.com> wrote:

> I vote for option 2.
>
> Regards,
> Vikram Hosakote
> IRC:  vhosakot
>
> From: Ryan Hallisey 
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Monday, September 19, 2016 at 2:58 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro
> support
>
> option 2
>
> Thanks
> -Ryan
>
> - Original Message -
> From: "Mauricio Lima" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Sent: Monday, September 19, 2016 2:21:51 PM
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro
> support
>
> Option 2
>
> 2016-09-19 14:56 GMT-03:00 Christian Berendt <
> bere...@betacloud-solutions.de > :
>
>
> Thanks for moving this forward.
>
> On 19 Sep 2016, at 19:40, Jeffrey Zhang < zhang.lei@gmail.com >
> wrote:
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
>
> +1 on option 2.
>
> __
> 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
>
> __
> 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
>
__
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] [vote][kolla] Splitting out Ansible into a separate deliverable

[Eduardo Gonzalez]

Option C

On Thu, Sep 15, 2016, 1:23 PM Dave Walker  wrote:

> Option C
>
> Thanks
>
> On 15 September 2016 at 12:10, Ryan Hallisey  wrote:
>
>> Option c.
>>
>> - Ryan
>>
>> > On Sep 15, 2016, at 4:33 AM, Paul Bourke 
>> wrote:
>> >
>> > c)   Split the repository shortly after tagging 3.0.0 – creating a
>> kolla-ansible deliverable for Ocata.
>> >
>> >> On 15/09/16 07:12, Steven Dake (stdake) wrote:
>> >> Core Reviewers:
>> >>
>> >>
>> >>
>> >> The facts:
>> >>
>> >> We have roughly 250 bugs in rc2.  Of those, I suspect over half can
>> just
>> >> be closed out as dupes, fixed, wontfix, or the like.
>> >>
>> >> The core reviewer team has had various discussions around splitting the
>> >> repository at various times but has not come to a concrete conclusion
>> >> via a vote.
>> >>
>> >> Once RC1 is tagged, the stable/newton branch will be created
>> automatically.
>> >>
>> >> All rc2 bug fixes will require bug IDs and backports to stable/newton
>> to
>> >> enable the ability to manage the release of rc2 and 3.0.0.
>> >>
>> >> There is an expectation for core reviewers to do the work of
>> backporting
>> >> to stable/newton – only our backports team typically does this work –
>> >> however during release we really need everyone’s participation.
>> >>
>> >>
>> >>
>> >> My understanding of general consensus beliefs:
>> >>
>> >> We believe splitting out the Ansible implementation into a separate
>> >> repository will produce a better outcome for both Kolla-Ansible and
>> >> Kolla-Kubernetes
>> >>
>> >> We have been unable to achieve consensus on the right timing for a repo
>> >> split in the past but generally believe the timing is right at some
>> >> point between rc1 and Summit or shortly thereafter, if we are to do the
>> >> repo split during Newton or very early Ocata.)
>> >>
>> >>
>> >>
>> >> This vote is a multiple choice (one choice please) vote.  Feel free to
>> >> discuss before making a decision.
>> >>
>> >>
>> >>
>> >> Please vote:
>> >>
>> >> a)   Do not split the repository between rc1 and Summit or shortly
>> >> thereafter at all, keeping the Ansible implementation intact in Ocata
>> >>
>> >> b)   Split the repository shortly after tagging RC1 – creating of a
>> >> kolla-ansible deliverable for Ocata.
>> >>
>> >> c)   Split the repository shortly after tagging 3.0.0 – creating a
>> >> kolla-ansible deliverable for Ocata.
>> >>
>> >>
>> >>
>> >> Voting is open for 7 days until September 21^st , 2016. Please do not
>> >> abstain on this critical vote.  Remember, no veto vote is available in
>> >> roll-call votes.  If a majority can’t be reached on any one choice, but
>> >> there is a majority around B & C, (which are the same idea, but
>> >> different timing) a second vote will be triggered around when to split
>> >> the repository.  The implication there is if you vote for b or c, your
>> >> voting for a repository split.  If you vote for A you are voting for no
>> >> repository split.  I hate to overload voting in this way.  It is only
>> an
>> >> optimization to speed things up as execution may need to happen now, or
>> >> can be pushed out a month, or may not be needed at this time.
>> >>
>> >>
>> >>
>> >> Regards
>> >>
>> >> -steve
>> >>
>> >>
>> >>
>> >>
>> __
>> >> 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
>> __
>> 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
>
__
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] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

[Eduardo Gonzalez]

+1

On Thu, Sep 8, 2016, 5:00 AM Steven Dake (stdake)  wrote:

> Kolla core reviewer team,
>
>
>
> It is my pleasure to nominate Christian Berendt for the Kolla core team.
>
>
>
> Christian’s output over the last cycle has been fantastic – cracking the
> top 10 reviewer list for the full cycle.  His 30 day stats [1] place him in
> solid 7th position, and considering the size of the core review team we
> have, this is a great accomplishment.  Christian also has solid 60 day
> review stats [2] place him in solid 7th position.  But more importantly
> his reviews are of high quality.  He has great IRC participation as well as
> having implemented all kinds of bug fixes all over the code base.  He
> clearly understands Kolla by the quality of his reviews.
>
>
>
> Consider this nomination a +1 vote from me.
>
>
>
> A +1 vote indicates you are in favor of Christian as a candidate, a 0 vote
> indicates an abstain, and a -1 is a veto.  Voting is open for 7 days until
> September 15th, or a unanimous response is reached or a veto vote
> occurs.  If a unanimous response is reached or a veto occurs, voting will
> close early.
>
>
>
> Regards,
>
> -steve
>
>
>
> [1] http://stackalytics.com/report/contribution/kolla/30
>
> [2] http://stackalytics.com/report/contribution/kolla/60
>
>
> __
> 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] [kolla][vote] Core nomination for Dave Walker (Daviey on irc)

[Eduardo Gonzalez]

+1

On Wed, Aug 24, 2016, 1:25 PM Martin André  wrote:

> +1
>
> On Tue, Aug 23, 2016 at 10:45 PM, Steven Dake (stdake) 
> wrote:
> > Kolla core reviewers,
> >
> > I am nominating Dave Walker for the Kolla core reviewer team.  His 30 day
> > review stats [1] place him in the middle of the pack for reviewers and
> his
> > 60 day stats[2] are about equivalent.  Dave participates heavily in IRC
> and
> > has done some good technical work including the Watcher playbook and
> > container.  He also worked on Sensu, but since we are unclear if we are
> > choosing Sensu or Tig, that work is on hold.  He will also be helping us
> > sort out how to execute with PBR going into the future on our stable and
> > master branches.  Dave has proven to me his reviews are well thought out
> and
> > he understands the Kolla Architecture.  Dave is part time like many Kolla
> > core reviewers and is independent of any particular affiliation.
> >
> > Consider this nomination as a +1 from me.
> >
> > As a reminder, a +1 vote indicates you approve of the candidate, an
> abstain
> > vote indicates you don't care or don't know for certain, and a –1 vote
> > indicates a veto.  If a veto occurs or a unanimous response is reached
> prior
> > to our 7 day voting window which concludes on August 30th, voting will be
> > closed early.
> >
> > [1] http://stackalytics.com/report/contribution/kolla/30
> > [2] http://stackalytics.com/report/contribution/kolla/60
> >
> >
> __
> > 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
>
__
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] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

[Eduardo Gonzalez]

Thanks all for the support. I will do my best.

Regards

On Fri, Aug 19, 2016, 9:28 PM Steven Dake (stdake) <std...@cisco.com> wrote:

> Eduardo,
>
> Their was a unanimous response in votes with no veto on this core reviewer
> nomination.  As a result, voting is closed early.
>
> Welcome to the Kolla core review team!  Looking for further good work from
> you!  I have added you to the kolla-core team in gerrit.  You should have
> access to full +2/-2 voting rights on patches, as well as voting rights on
> Kolla's policy votes.  If you need a primer ping me or another core
> reviewer.
>
> Regards
> -steve
>
>
> From: Steven Dake <std...@cisco.com>
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, August 18, 2016 at 4:09 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [vote][kolla] Core nomination proposal for
> Eduardo Gonzalez Gutierrez (egonzales90 on irc)
>
> Kolla Core Review Team:
>
> I am nominating Eduardo for the core reviewer team.  His reviews are
> fantastic, as I'm sure most of you have seen after looking over the review
> queue.  His 30 day stats place him at #3 by review count [1] and 60 day
> stats [2] at #4 by review count.  He is also first to review a significant
> amount of the time – which is impressive for someone new to Kolla.  He
> participates in IRC and he has done some nice code contribution as well [3]
> including the big chunk of work on enabling Senlin in Kolla, the dockerfile
> customizations work, as well as a few documentation fixes.  Eduardo is not
> affiliated with any particular company.  As a result he is not full time on
> Kolla like many of our other core reviewers.  The fact that he is part time
> and still doing fantastically well at reviewing is a great sign of things
> to come :)
>
> Consider this nomination as my +1 vote.
>
> Voting is open for 7 days until August 24th.  Joining the core review team
> requires a majority of the core review team to approve within a 1 week
> period with no veto (-1) votes.  If a veto or unanimous decision is reached
> prior to August 24th, voting will close early.
>
> Regards
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla/30
> [2] http://stackalytics.com/report/contribution/kolla/60
> [3]
> https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2540gmail.com%253E%22
>
> __
> 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