Re: [openstack-dev] [puppet][tripleo] Why is this acceptance test failing?
On Wed, Jul 04, 2018 at 07:51:20PM -0600, Emilien Macchi wrote:
> The actual problem is that the manifest isn't idempotent anymore:
> http://logs.openstack.org/47/575147/16/check/puppet-openstack-beaker-centos-7/3f70cc9/job-output.txt.gz#_2018-07-04_00_42_19_705516
Hey Emilien, thanks for taking a look. I'm not following -- or maybe
I'm just misreading the failure message. It really looks to me as if
the failure is caused by a regular expression; it says:
Failure/Error:
apply_manifest(pp, :catch_changes => true) do |result|
expect(result.stderr)
.to include_regexp([/Puppet::Type::Keystone_tenant::ProviderOpenstack:
Support for a resource without the domain.*using 'Default'.*default domain id
is '/])
end
And yet, the regular expression in that check clearly matches the
output shown in the failure message. What do you see that points at an
actual idempotency issue?
(I wouldn't be at all surprised to find an actual problem in this
change; I've fixed several already. I'm just not sure how to turn
this failure into actionable information.)
--
Lars Kellogg-Stedman | larsks @ {irc,twitter,github}
http://blog.oddbit.com/|
__
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] [puppet][tripleo] Why is this acceptance test failing?
The actual problem is that the manifest isn't idempotent anymore:
http://logs.openstack.org/47/575147/16/check/puppet-openstack-beaker-centos-7/3f70cc9/job-output.txt.gz#_2018-07-04_00_42_19_705516
So something in your patch is breaking the Keystone_domain provider and
makes it non idempotent.
On Tue, Jul 3, 2018 at 7:30 PM Lars Kellogg-Stedman wrote:
> I need another set of eyes.
>
> I have a review that keeps failing here:
>
>
> http://logs.openstack.org/47/575147/16/check/puppet-openstack-beaker-centos-7/3f70cc9/job-output.txt.gz#_2018-07-04_00_42_19_696966
>
> It's looking for the regular expression:
>
> /Puppet::Type::Keystone_tenant::ProviderOpenstack: Support for a
> resource without the domain.*using 'Default'.*default domain id is '/
>
> The output shown in the failure message contains:
>
> [1;33mWarning: Puppet::Type::Keystone_tenant::ProviderOpenstack:
> Support for a resource without the domain set is deprecated in
> Liberty cycle. It will be dropped in the M-cycle. Currently using
> 'Default' as default domain name while the default domain id is
> '7ddf1dfa7fac46679ba7ae2245bece2f'.[0m
>
> The regular expression matches the text! The failing test is here:
>
>
> https://github.com/openstack/puppet-keystone/blob/master/spec/acceptance/default_domain_spec.rb#L59
>
> I've been staring at this for a while and I'm not sure what's going
> on.
>
> --
> Lars Kellogg-Stedman | larsks @ {irc,twitter,github}
> http://blog.oddbit.com/|
>
> __
> 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
>
--
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-I18n] [I18n] IRC Office hours: 2018/07/05 13:00-14:00 UTC
Hello, I am also available on today office hour - anyone interested in I18n office hours subscribing openstack-dev mailing list is also welcome :) With many thanks, /Ian Frank Kloeker wrote on 7/3/2018 6:30 PM: Hello, good to be back. Still sorting emails, messages and things. Let's meet on Thursday in our team meeting in the new Office Hour format: 2018/07/05 13:00-14:00 UTC If you have anything to share please let us know on wiki page [1] kind regards Frank [1] https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting ___ OpenStack-I18n mailing list openstack-i...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n __ 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] [congress] meeting cancelled
Hi all, I’m not going to be able to make the meeting this week. Let’s resume next week =) I’m still available by email. Thanks! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Technical Committee Update for 3 July
On 2018-07-04 16:38:41 -0500 (-0500), Sean McGinnis wrote: [...] > I would propose based on this lack of feedback that we go back to > just having our predesignated office hour times, and anyone > interested in catching up on what, if anything, was discussed > during office hours can go to the the point in the IRC logs that > they are interested in. [...] Heartily seconded. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Technical Committee Update for 3 July
>
> Office hour logs from last week:
>
> * http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-27-01.00.html
> * http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-28-15.00.html
> * http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-07-03-09.01.html
>
> In the absence of any feedback about using the meeting bot to record the
> office hours, we will continue to do so, for now.
>
I would say the absence of feedback is an indication that there isn't anyone
that sees a strong benefit for doing it this way. Or at least strong enough to
step forward and say they prefer it.
I would propose based on this lack of feedback that we go back to just having
our predesignated office hour times, and anyone interested in catching up on
what, if anything, was discussed during office hours can go to the the point in
the IRC logs that they are interested in.
That also allows for picking up on any other things that were discussed in the
channel that ended up before or after someone did the #{start|end}meeting
action.
__
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] [packaging-rpm] PTL on vacation
Hi, I will be on vacation between July 9th and July 27th, without much e-mail access depending on the specific day. Jakub Ruzicka (jruzicka) will be my deputy during that time. Regards, Javier __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] [all] TC Report 18-26
Tried hard to avoid this thread, but this message is so much wrong..
On 07/03/2018 09:48 PM, Fox, Kevin M wrote:
I don't dispute trivial, but a self hosting k8s on bare metal is not incredibly
hard. In fact, it is easier then you might think. k8s is a platform for
deploying/managing services. Guess what you need to provision bare metal? Just
a few microservices. A dhcp service. dhcpd in a daemonset works well. some pxe
infrastructure. pixiecore with a simple http backend works pretty well in
practice. a service to provide installation instructions. nginx server handing
out kickstart files for example. and a place to fetch rpms from in case you
don't have internet access or want to ensure uniformity. nginx server with a
mirror yum repo. Its even possible to seed it on minikube and sluff it off to
its own cluster.
The main hard part about it is currently no one is shipping a reference
implementation of the above. That may change...
It is certainly much much easier then deploying enough OpenStack to get a self
hosting ironic working.
Side note: no, it's not. What you describe is similarly hard to installing
standalone ironic from scratch and much harder than using bifrost for
everything. Especially when you try to do it in production. Especially with
unusual operating requirements ("no TFTP servers on my network").
Also, sorry, I cannot resist:
"Guess what you need to orchestrate containers? Just a few things. A container
runtime. Docker works well. some remove execution tooling. ansible works pretty
well in practice. It is certainly much much easier then deploying enough k8s to
get a self hosting containers orchestration working."
Such oversimplications won't bring us anywhere. Sometimes things are hard
because they ARE hard. Where are people complaining that installing a full
GNU/Linux distributions from upstream tarballs is hard? How many operators here
use LFS as their distro? If we are okay with using a distro for GNU/Linux, why
using a distro for OpenStack causes so much contention?
Thanks,
Kevin
From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, July 03, 2018 10:06 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] [all] TC Report 18-26
On 07/02/2018 03:31 PM, Zane Bitter wrote:
On 28/06/18 15:09, Fox, Kevin M wrote:
* made the barrier to testing/development as low as 'curl
http://..minikube; minikube start' (this spurs adoption and
contribution)
That's not so different from devstack though.
* not having large silo's in deployment projects allowed better
communication on common tooling.
* Operator focused architecture, not project based architecture.
This simplifies the deployment situation greatly.
* try whenever possible to focus on just the commons and push vendor
specific needs to plugins so vendors can deal with vendor issues
directly and not corrupt the core.
I agree with all of those, but to be fair to OpenStack, you're leaving
out arguably the most important one:
* Installation instructions start with "assume a working datacenter"
They have that luxury; we do not. (To be clear, they are 100% right to
take full advantage of that luxury. Although if there are still folks
who go around saying that it's a trivial problem and OpenStackers must
all be idiots for making it look so difficult, they should really stop
embarrassing themselves.)
This.
There is nothing trivial about the creation of a working datacenter --
never mind a *well-running* datacenter. Comparing Kubernetes to
OpenStack -- particular OpenStack's lower levels -- is missing this
fundamental point and ends up comparing apples to oranges.
Best,
-jay
__
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] [nova]API update week 28-4
Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === We have re-started the Nova API discussion in office hour. I have updated the wiki page for more information about office hours: https://wiki.openstack.org/wiki/Meetings/NovaAPI What we discussed this week: - This was the first office hours after long time. - Collected the API related BPs on etherpad (rocky-nova-priorities-tracking) for review. - Created the weekly bug report etherpad and we will track down the number there. - Home work for API subteam to at least review 3 in-progress bug patches. - From next week we will do some online bug triage/review or discussion around ongoing BP. Planned Features : == Below are the API related features for Rocky cycle. Nova API Sub team will start reviewing those to give their regular feedback. If anythings missing there feel free to add those in etherpad- https://etherpad.openstack.org/p/rocky-nova-priorities-tracking 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names - Spec Update need another +2 - https://review.openstack.org/#/c/558125/ - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged) - Weekly Progress: On Hold. Waiting for spec update to merge first. 2. Abort live migration in queued state: - https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status - https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+(status:open+OR+status:merged) - Weekly Progress: Code is up for review. No Review last week. 3. Complex anti-affinity policies: - https://blueprints.launchpad.net/nova/+spec/complex-anti-affinity-policies - https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged) - Weekly Progress: Code is up for review. Few reviews done . 4. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged) - Weekly Progress: Waiting to hear from mriedem about his WIP on base patch - https://review.openstack.org/#/c/569649/3 5. API Extensions merge work - https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-rocky - https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-rocky - Weekly Progress: Good progress. 1/3 part is merged. Bugs: We discussed in office hour to start reviewing the in-progress bugs and minimize the number. From next week, I will show the weekly progress on the bug numbers. Current Bugs Status: Critical bug 0 High importance bugs 2 Status: New bugs 0 Confirmed/Triage 30 In-progress bugs 36 Incomplete:4 = Total:70 NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those are not in above list. Tag such bugs so that we can keep our eyes. Ref: https://etherpad.openstack.org/p/nova-api-weekly-bug-report -gmann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-community] DevStack Installation issue
Hi, Sorry, Neither of those paths are vaild. Still stuck. (attached log generated during installation). ~Thanx Abhijit From: Slawomir Kaplonski Sent: Saturday, June 30, 2018 5:57 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [openstack-community] DevStack Installation issue Hi, In error log there is info that placement API service didn’t start properly. You should then go to placement API logs (/var/log/nova/ or /opt/stack/logs/nova probably) and check there what was wrong with it. > Wiadomość napisana przez Abhijit Dutta w dniu > 30.06.2018, o godz. 18:51: > > Hi All, > > Any help here will be appreciated. > > ~Thanx > Abhijit > > From: Abhijit Dutta > Sent: Friday, June 29, 2018 8:10 AM > To: Dr. Jens Harbott (frickler); OpenStack Development Mailing List (not for > usage questions) > Subject: Re: [openstack-dev] [openstack-community] DevStack Installation issue > > Hi, > > As advised I installed Fedora 27 (Workstation) and tried with the latest > version of devstack (pulled from git). However this time I got the following > error - > > ./stack.sh:1313:start_placement > /opt/stack/devstack/lib/placement:184:start_placement_api > /opt/stack/devstack/lib/placement:179:die > [ERROR] /opt/stack/devstack/lib/placement:179 placement-api did not start > Error on exit > World dumping... see /opt/stack/logs/worlddump-2018-06-29-071219.txt for > details (attached) > > The local.cnf has been configured as: > > [[local|localrc]] > FLOATING_RANGE=192.168.1.224/27 > FIXED_RANGE=10.11.12.0/24 > FIXED_NETWORK_SIZE=256 > FLAT_INTERFACE=eth0 > ADMIN_PASSWORD=supersecret > DATABASE_PASSWORD=iheartdatabases > RABBIT_PASSWORD=flopsymopsy > SERVICE_PASSWORD=iheartksl > > I have configured a static IP which is 192.168.1.201 in my laptop, which has > dual core and 3gigs RAM. > > Please let me know, what can cause this error. > > ~Thanx > Abhijit > > > > > From: Dr. Jens Harbott (frickler) > Sent: Wednesday, June 27, 2018 3:53 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: Abhijit Dutta > Subject: Re: [openstack-dev] [openstack-community] DevStack Installation issue > > 2018-06-27 16:58 GMT+02:00 Amy Marrich : > > Abhijit, > > > > I'm forwarding your issue to the OpenStack-dev list so that the right people > > might see your issue and respond. > > > > Thanks, > > > > Amy (spotz) > > > > -- Forwarded message -- > > From: Abhijit Dutta > > Date: Wed, Jun 27, 2018 at 5:23 AM > > Subject: [openstack-community] DevStack Installation issue > > To: "commun...@lists.openstack.org" > > > > > > Hi, > > > > > > I am trying to install DevStack for the first time in a baremetal with > > Fedora 28 installed. While executing the stack.sh I am getting the > > following error: > > > > > > No match for argument: Django > > Error: Unable to find a match > > > > Can anybody in the community help me out with this problem. > > We are aware of some issues with deploying devstack on Fedora 28, > these are being worked on, see > https://review.openstack.org/#/q/status:open+project:openstack-dev/devstack+branch:master+topic:uwsgi-f28 > > If you want a quick solution, you could try deploying on Fedora 27 or > Centos 7 instead. > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev — Slawek Kaplonski Senior software engineer Red Hat __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev File System Summary === Filesystem Size Used Avail Use% Mounted on devtmpfs 1.5G 0 1.5G 0% /dev tmpfs1.5G 26M 1.5G 2% /dev/shm tmpfs1.5G 2.0M 1.5G 1% /run tmpfs1.5G 0 1.5G 0% /sys/fs/cgroup /dev/mapper/fedora-root 49G 7.6G 39G 17% / tmpfs1.5G 656K 1.5G 1% /tmp /dev/sda3976M 144M 766M 16% /boot /dev/mapper/fedora-home 67G 148M 64G 1% /home tmpfs294M 20K 294M 1% /run/user/42 tmpfs294M 4.6M 289M 2% /run/user/1000 tmpfs294M 0 294M 0% /run/user/1001 Process Listing === ps axo user,ppid,pid,pcpu,pmem,vsz,rss,tty,stat,start,time,args --- USER PPID PID %CPU %MEMVSZ RSS TT STAT STARTED TIME COMMAND root 0 1 0.1 0.2 167528 6212 ?Ss 01:11:07 00:00:09 /usr/lib/systemd/systemd --system --deserialize 23 root 0 2 0.0 0.0
[openstack-dev] [cyborg]Weekly Team Meeting 2018.07.04
Hi Team, We will have our weekly meeting as usual at #openstack-cyborg starting UTC1400. The main focus is to align the development status. -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ 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
