Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-2339

add centos-7 to the provisioiner matrix

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: 1.2.0
    • Component/s: provisioner
    • Labels:
      None

      Description

      Provisioner needs to be able to deploy on centos-7, as centos-6 won't be supported in the coming release.

        Issue Links

          Activity

          Hide
          cos Konstantin Boudnik added a comment -

          I have tested the provisioning with the new deploy centos-7 image and it works as expected. Ready to get committed.

          Show
          cos Konstantin Boudnik added a comment - I have tested the provisioning with the new deploy centos-7 image and it works as expected. Ready to get committed.
          Hide
          cos Konstantin Boudnik added a comment -

          Damn, the deploy does work, however starting the services on centos-7 is failing badly because systemctl throws the following error:

          Failed to get D-Bus connection: Operation not permitted
          

          Not sure, if there's a workaround for this.

          Show
          cos Konstantin Boudnik added a comment - Damn, the deploy does work, however starting the services on centos-7 is failing badly because systemctl throws the following error: Failed to get D-Bus connection: Operation not permitted Not sure, if there's a workaround for this.
          Hide
          cos Konstantin Boudnik added a comment -

          Pocking around a bit..., looks like this is the stinky systemd again ;( OMG, what a crap!?

          Show
          cos Konstantin Boudnik added a comment - Pocking around a bit..., looks like this is the stinky systemd again ;( OMG, what a crap!?
          Hide
          cos Konstantin Boudnik added a comment -

          Funnily enough, if I were to use old-fashion init-scripts, they start they services, although the cursing is still printed out. I wonder if there's a way to force puppet not to use systemctl on centos7

          Show
          cos Konstantin Boudnik added a comment - Funnily enough, if I were to use old-fashion init-scripts, they start they services, although the cursing is still printed out. I wonder if there's a way to force puppet not to use systemctl on centos7
          Hide
          warwithin YoungWoo Kim added a comment - - edited

          Enforcing the service provider to 'init'? I'm not sure that will solve the problem https://ask.puppetlabs.com/question/396/howto-force-systemd-as-service-provider-globally/

          Show
          warwithin YoungWoo Kim added a comment - - edited Enforcing the service provider to 'init'? I'm not sure that will solve the problem https://ask.puppetlabs.com/question/396/howto-force-systemd-as-service-provider-globally/
          Hide
          oflebbe Olaf Flebbe added a comment -

          hey Konstantin Boudnik no need to swear. This is not systemd fault, it's our fault, or more like the way we use puppet

          On one side we have to target bare metal /vm and on the other side we need to adress more like a microservices setup.
          On the bare metal /vm side we have to handle the systemd , in docker we do not have an init system, we are faking it.

          Using puppet as an abstraction for both will not work here, since it has to handle services very differently, but puppet has no clue how.

          Either implement an abstraction to handle both cases or implement both.

          I am thinking about this problem for quite a bit. Since I am now more comfortable with docker I am thinking about to throw away the bare metal support / systemd /sysv init.d support completly and only support microservices within containers for all our components.

          That would make render rebuilding of all our packages in whatever distro alot easier ... and we could use docker-swarm or kubernetes to boot up a smoke test environment out of the box.

          That way we are parting from the traditional hadoop setups, but it will make our work alot more comfortable.

          Surely this sounds like bigtop-2.0 ... but that's definetly the direction I see the most promising solution to some of our problems.

          Show
          oflebbe Olaf Flebbe added a comment - hey Konstantin Boudnik no need to swear. This is not systemd fault, it's our fault, or more like the way we use puppet On one side we have to target bare metal /vm and on the other side we need to adress more like a microservices setup. On the bare metal /vm side we have to handle the systemd , in docker we do not have an init system, we are faking it. Using puppet as an abstraction for both will not work here, since it has to handle services very differently, but puppet has no clue how. Either implement an abstraction to handle both cases or implement both. I am thinking about this problem for quite a bit. Since I am now more comfortable with docker I am thinking about to throw away the bare metal support / systemd /sysv init.d support completly and only support microservices within containers for all our components. That would make render rebuilding of all our packages in whatever distro alot easier ... and we could use docker-swarm or kubernetes to boot up a smoke test environment out of the box. That way we are parting from the traditional hadoop setups, but it will make our work alot more comfortable. Surely this sounds like bigtop-2.0 ... but that's definetly the direction I see the most promising solution to some of our problems.
          Hide
          cos Konstantin Boudnik added a comment -

          Yeah, it seems like a way to tell puppet not to use systemd. I will give it a try today/tomorrow. Thanks for the link!

          Show
          cos Konstantin Boudnik added a comment - Yeah, it seems like a way to tell puppet not to use systemd. I will give it a try today/tomorrow. Thanks for the link!
          Hide
          cos Konstantin Boudnik added a comment -

          Hey Olaf Flebbe - I am not swearing: I called a spade a spade
          Anyway, what you saying makes sense. And perhaps it is the time to move towards the microservice'ish architecture. jay vyas tried to bring up this topic a few times in the dev@ already, but perhaps now is the right time to think about how we should do it.
          In the meantime, forcing Puppet to use init.d might be a sensible workaround.

          Show
          cos Konstantin Boudnik added a comment - Hey Olaf Flebbe - I am not swearing: I called a spade a spade Anyway, what you saying makes sense. And perhaps it is the time to move towards the microservice'ish architecture. jay vyas tried to bring up this topic a few times in the dev@ already, but perhaps now is the right time to think about how we should do it. In the meantime, forcing Puppet to use init.d might be a sensible workaround.
          Hide
          cos Konstantin Boudnik added a comment -

          With this workaround in place centos-7 deployment is fully functional.
          Unless I hear any objections to the workaround I will commit this in a day or so. Using

          Service {
            provider => init,
          }
          

          in the top-level site.pp allows to fix the issue for all the modules at once. Which is good as we are likely to step on the same issue with Ubuntu 15.04.

          Let's deal with a better deployment model in a separate JIRA.

          Show
          cos Konstantin Boudnik added a comment - With this workaround in place centos-7 deployment is fully functional. Unless I hear any objections to the workaround I will commit this in a day or so. Using Service { provider => init, } in the top-level site.pp allows to fix the issue for all the modules at once. Which is good as we are likely to step on the same issue with Ubuntu 15.04. Let's deal with a better deployment model in a separate JIRA.
          Hide
          jayunit100 jay vyas added a comment -

          Agree we should just deploy containers and let the user pick their operating system . We should be focusing on vertical interop

          Show
          jayunit100 jay vyas added a comment - Agree we should just deploy containers and let the user pick their operating system . We should be focusing on vertical interop
          Hide
          oflebbe Olaf Flebbe added a comment -

          +1

          Show
          oflebbe Olaf Flebbe added a comment - +1
          Hide
          cos Konstantin Boudnik added a comment -

          Pushed to the master. Thanks for the ideas and review!

          Show
          cos Konstantin Boudnik added a comment - Pushed to the master. Thanks for the ideas and review!

            People

            • Assignee:
              cos Konstantin Boudnik
              Reporter:
              cos Konstantin Boudnik
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development