Re: [foreman-dev] Re: 1.15 branching in approximately 2 weeks
Two updates: foreman-packaging RPMs have been branched to rpm/1.15 and updated per the release process instructions (mmoll is awaiting one change to get in before he branches the debian branch per IRC conversation). Katello (katello, katello-installer, katello-packaging) have all been officially branched, tags created in koji and mash scripts generated. If anyone has time, a docs PR has been opened to create the 3.4 docs based off of nightly [1]. There are currently 11 issues marked against 3.4.0 [2] any help review or tackling them is much appreciated. Expect RC1 to align with Foreman RC1 per the rough schedule [3]. The Katello puppet modules will need to be released in the next few days. Ewoud has started a list of PRs he'd like to see get in before those releases are cut [4]. Again, if anyone has some time to spare for review and testing it would be much appreciated to ensure a smooth RC1. [1] https://github.com/theforeman/theforeman.org/pull/841 [2] https://goo.gl/atUExe [3] https://calendar.google.com/calendar/embed?src=gbmpm6r1rsfok5k633ii240bck%40group.calendar.google.com&ctz=America/New_York [4] https://pad-katello.rhcloud.com/p/modules-3.4 On Tue, Mar 28, 2017 at 11:33 AM, Tomas Strachota wrote: > hammer_cli 0.10.0 and hammer_cli_foreman 0.10.0 released: > > https://github.com/theforeman/hammer-cli/tree/0.10-stable > https://github.com/theforeman/hammer-cli-foreman/tree/0.10-stable > > PR into foreman-packaging with scratchbuilds: > https://github.com/theforeman/foreman-packaging/pull/1585 > > > > On Tue, Mar 28, 2017 at 1:57 PM, Daniel Lobato > wrote: > > Hi all, > > > > I will begin branching Foreman, theforeman.org, community-templates > > and translations in approximately 5 hours. > > If you have signed up to branch any of the projects in this thread, > > please feel free to do so any time today. > > > > Remember, after branching, we still have time to submit patches to > > ensure the release is stable during the RC period. > > Expect a new RC to come out every week approximately since now. > > > > Thanks for your collaboration! > > > > On Thu, Mar 16, 2017 at 11:45 AM, Dmitri Dolguikh > wrote: > >> On Wed, Mar 15, 2017 at 8:10 AM, Tomas Strachota > wrote: > >>> On Tue, Mar 14, 2017 at 2:28 PM, Daniel Lobato > wrote: > We're planning to do the branching on all projects on March 28th - > please keep it in mind and try to get > things that would be important for 1.15 by then. > > I do not have commit access everywhere, so please check the following > list and reply if you > could take care of cherry-picking and branching: > > foreman - Daniel - dlobatog > foreman-installer - Stephen - stbenjam > smart-proxy - Daniel - dlobatog - (or Dmitri - witlessb if you prefer) > >> > >> yes can do. > >> -d > >> > foreman-selinux - Lukas - lzap > foreman-packaging - Eric - ehelms > theforeman.org - Daniel - dlobatog > translations - Daniel - dlobatog > community-templates - Daniel - dlobatog > hammer-cli - Tomas? Martin? > hammer-cli-foreman - Tomas? Martin? > >>> > >>> I'll take care of hammer branching and release. > >>> > puppet-foreman - ? > puppet-foreman_proxy - ? > > > On Fri, Mar 10, 2017 at 7:43 PM, Daniel Lobato Garcia > wrote: > > As per http://projects.theforeman.org/projects/foreman/wiki/ > Foreman_115_Schedule, > > 1.15 is due to be branched soon, in 2 weeks approximately. > > > > Please help to make develop more stable during this process, be it > through > > thorough testing, bugfixing or improving documentation. > > > > Help with updating the manual would be appreciated, see the list of > > tasks in: > > - https://github.com/theforeman/theforeman.org/issues/765 > > > > Some translations are nearing 100% completion, we welcome > contributions > > that help finishing them for the next release: > > - https://www.transifex.com/foreman/foreman/foreman/ > > > > If you have any critical fixes that you think should be included in > 1.15 > > in any of the core projects, please reply to this read to raise > > attention over them. Maintainers feel free to set the 1.15 label to > > any PR of that nature. > > > > Best, > > > > -- > > Daniel Lobato Garcia > > > > @dLobatog > > blog.daniellobato.me > > daniellobato.me > > > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search= > 0x7A92D6DD38D6DE30 > > Keybase: https://keybase.io/elobato > > > > -- > Daniel Lobato > > @dlobatog > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search= > 0x7A92D6DD38D6DE30 > > -- > You received this message because you are subscribed to the Google > Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to foreman-dev+unsubscr...@
Re: [foreman-dev] CLI Integration Management
Can we get the tests into bats instead of non-live-server? I think that's the only way issues with authorization, etc. are going to be found. I agree all the modules should be part of the suite. On Wed, Mar 29, 2017 at 5:48 PM, Andrew Kofink wrote: > Hello CLI maintainers, > > (TL;DR I'm tired of broken tests in hammer-cli-katello due to hammer-cli > changes) > > We have a complex dependency structure between our CLI libraries > (hammer-cli, hammer-cli-foreman, hammer-cli-katello, csv, admin, etc.), and > it's not necessarily immune to changes in lower projects (i.e. hammer-cli). > An example is this recent PR (https://github.com/theforeman > /hammer-cli/pull/233) that slightly changes the options/all_options > methods in the abstract command. This caused failures in hammer-cli-katello > where we override/extend those methods, and I had to open a PR to address > the changes. > > I'd like to start a discussion on ways to keep this from happening in the > future. Some solutions I've thought of include (1) mentioning people on PRs > that have the potential to break dependent projects and (2) running > dependent projects' tests when a PR is submitted. > > (1) is not very robust. People can easily forget to mention others, and > it's difficult to remember all the appropriate people to mention. > > (2) seems like more of a pain for maintainers of the lower projects > (hammer-cli). If we went with this, it would still be up to the dependent > projects to update to adapt to the changes in hammer-cli. It has the > benefit of immediately alerting the maintainers that a breaking change is > incoming. Overall, the hammer tests run in seconds; I think > hammer-cli-foreman is the longest-running at ~120 seconds. hammer-cli runs > in less than a second, and hammer-cli-katello runs in about 5 seconds. > > Let me know what you think! > > - Andrew > > -- > Andrew Kofink > akof...@redhat.com > IRC: akofink > Associate Software Engineer > Red Hat Satellite > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[foreman-dev] CLI Integration Management
Hello CLI maintainers, (TL;DR I'm tired of broken tests in hammer-cli-katello due to hammer-cli changes) We have a complex dependency structure between our CLI libraries (hammer-cli, hammer-cli-foreman, hammer-cli-katello, csv, admin, etc.), and it's not necessarily immune to changes in lower projects (i.e. hammer-cli). An example is this recent PR (https://github.com/ theforeman/hammer-cli/pull/233) that slightly changes the options/all_options methods in the abstract command. This caused failures in hammer-cli-katello where we override/extend those methods, and I had to open a PR to address the changes. I'd like to start a discussion on ways to keep this from happening in the future. Some solutions I've thought of include (1) mentioning people on PRs that have the potential to break dependent projects and (2) running dependent projects' tests when a PR is submitted. (1) is not very robust. People can easily forget to mention others, and it's difficult to remember all the appropriate people to mention. (2) seems like more of a pain for maintainers of the lower projects (hammer-cli). If we went with this, it would still be up to the dependent projects to update to adapt to the changes in hammer-cli. It has the benefit of immediately alerting the maintainers that a breaking change is incoming. Overall, the hammer tests run in seconds; I think hammer-cli-foreman is the longest-running at ~120 seconds. hammer-cli runs in less than a second, and hammer-cli-katello runs in about 5 seconds. Let me know what you think! - Andrew -- Andrew Kofink akof...@redhat.com IRC: akofink Associate Software Engineer Red Hat Satellite -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] [RFC] - Proxies with multiple interfaces
On Mon, Mar 27, 2017 at 3:10 PM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > On Wed, Mar 22, 2017 at 04:44:51PM +, Sean O'Keeffe wrote: > > On Wed, Mar 22, 2017 at 1:40 PM, Ewoud Kohl van Wijngaarden < > > ew...@kohlvanwijngaarden.nl> wrote: > > > > > On Mon, Mar 20, 2017 at 03:50:30PM +, Sean O'Keeffe wrote: > > > > On Mon, Mar 20, 2017 at 2:25 PM, Lukas Zapletal > wrote: > > > > > Can you elaborate more on motivation? Multi-homed proxy is still > one > > > > > instance, why would > > > > > Foreman need to reach to it in two different ways? > > > > > > > > This is for clients to reach a proxy in the different ways, NOT > foreman. > > > > > > > > > > > > > Isn't the result always the same (a change on the same instance)? > How > > > > > about relaxing > > > > > the constraing when each individual proxy must have unique URL? > Just > > > > > checking before introducing another table (more SQL joins and query > > > > > complexity). > > > > > > > > > If a Host / HostGroups can be assigned a URL/Hostname instead of a > proxy > > > > its useful for Multi-homing, loadbalancing & NAT'ed environments, > maybe > > > > others? > > > > What does relaxing the unique URL constrain actually give us? I > think if > > > > you have 2 proxies with the same URL that's just effectively > duplicating > > > > the object? > > > > > > > > Or if you mean creating 2 proxies with different URLs (an external & > and > > > > another internal one) I think would be problematic when Foreman > needs to > > > > talk to the Proxy. E.g Host needs to talk to > proxy1-external.example.com > > > > but foreman must talk to the proxy via proxy1-internal.example.com. > If > > > we > > > > have 2 proxies in foreman ( proxy1-internal & proxy1-external ) and > you > > > > assign a host proxy1-external foreman would try to connect to > > > > proxy1-external.example.com to create a DHCP or DNS or something > else > > > with > > > > would not work. > > > > > > I think a different URL for clients and Foreman itself makes a lot of > > > sense. Now I have some trouble reading the design from the code. Could > > > you describe how this would be used by a user? Maybe a screenshot from > > > the new configuration page. > > > > > > > Sure, > > > > I've added another tab to the Smart Proxies form, where you can add > > "Secondary URLs". On the Host/Hostgroup from the user can then select a > URL > > for attributes like Puppet Master, Puppet CA (and Openscap and content > > source for those plugins). I've uploaded some pictures to the PR as well > > which should explain it much better. > > > > https://github.com/theforeman/foreman/pull/4346#issuecomment-288461410 > > > > One thing Stephen mentioned on the PR was if URLs could have many proxies > > as well as proxies have many URLs. That would go someway to better load > > balanced proxies. Which I think would be great, though I personally don't > > like the idea of another form & menu item just to create URLs, I think we > > have lots of forms and menu items already.. > > As a user it feels very complex and overwhelming. This is a perfect > example where a use case for a complex deployment makes it harder for > simple deployments. > > I'm not against it, but just some thinking out loud to see if we both > get what the impact is. > > How often do you have multiple URLs? My feeling is that there are the > following use cases: > > # A proxy has 1 URL > > This is the current situation. Speaks for itself. Question here is how > you display a proxy with only 1 URL. Do you simplify it so it matches > the current UI or keep it consistent with multiple URLs? > I would say keeping the UI consistent with multiple URLs would be better, as it would look funny IMO if you have grouped options listing URLs/hostname and ungrouped options listing proxies names. maybe Roxanna or someone else has some input on this? Maybe we could: Just listing the Hostname? or if the URL has a Name attribute they could select a Name? Something like "Atlanta - Dev Network". @stbenjam suggested that on the PR. > # A proxy has 2 URLs > > Here we have a separate network for Foreman and its proxies. Then the > clients talk to their proxies on another network for other services > (puppet, DHCP etc). > That means we have a URL for the internal network and a URL for the > client network. > > # A proxy has multiple URLs for multiple clients > > A proxy could live in multiple client networks and serve them with > different names. I'm wondering how common this is and it's really an > added benefit. If you're separating anyway, maybe we should just > recommend deploying multiple proxies. > That's the currently way, but when you have lots of networks you end up having to have lots of unnecessary Proxies on small networks that otherwise wouldn't need it. > > Regarding the use case where a URL has multiple proxies: this is a proxy > cluster. You could reason the other way around. Let me explain that. > Currently a proxy ha
[foreman-dev] Re: Using sync task for running Ansible plays hangs Foreman
It actually just seems like the entire API is blocked when a sync task is triggered directly in the controller method. Does it have something to do with concurrency in Rails? Maybe also resources get locked producing a deadlock? Still would be happy about some suggestions. On Monday, March 13, 2017 at 11:09:45 AM UTC+1, gerrit.sc...@avid.com wrote: > > Hello, > > I have an issue with triggering synchronous tasks in foreman-tasks. I have > written a plugin that is triggering an Ansible Play as a foreman-tasks' > sync_task (the foreman_ansible plugin itself uses only asynchronous > tasks, but I want the request in my plugin to particularly block until the > triggered Ansible task has completed). During playbook execution, the > Ansible callback plugin reports gathered facts to the Foreman facts API, > which I need later. However, as soon as the callback plugin contacts the > facts API, Foreman starts hanging completely, not answering any requests > any longer. Restarting httpd makes Foreman in production usable again. > After restarting and trying the call again, the entire procedure often > works as expected, which makes it even more incomprehensible for me. The > problem does not happen at all when the Ansible callback plugin is not > configured. In this case the call always blocks and succeeds as expected. > Does anybody have any idea what could be the reason for this behaviour? And > is there any way to get around this problem? I'd be very grateful for any > hints. > > Regards > > --Gerrit > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
